mounts using go9p report 0 byte capacity (breaking Persistent Local Volumes)

[john-tipper]

When using OSX and mounting directories into Minikube, the capacity/size of the mounts is reported as 0 by df:

• How to replicate the error, including the exact command-lines used.

  mkdir ~/mymount
  minikube start

  minikube mount ~/mymount:/data/mymount &
  minikube ssh
  df /data/mymount

• The full output of the command that failed

  df /data/mymount/
  Filesystem 1K-blocks Used Available Use% Mounted on
  192.168.99.1 0 0 0 - /data/mymount

The background is that I'm trying to use Persistent Local Volumes with Minikube and OSX, with the static provisioner to create the PVs. This provisioner fails to create the PVs because the capacity of the mounts is seen by Minikube as being 0. (StackOverflow link to issue here: https://stackoverflow.com/questions/54993532/how-to-use-kubernetes-persistent-local-volumes-with-minikube-on-osx).

I get the same error if I use:

minikube start --mount --mount-string="~/mymount:/data/mymount"

• The operating system name and version used

OSX Mojave (10.14.3)
Minikube v0.34.1
Kubernetes v1.13.3

[tstromberg]

I can confirm with hyperkit and virtualbox drivers, as well as when supplying --9p-version=9p2000.L

Anyone have an idea how to get disk capacity plumbed through in 9p? Is it possible that 9p just doesn't allow for it?

[afbjorklund]

Same thing happens on linux.

192.168.99.1 on /mnt/sda1/data/mount type 9p (rw,relatime,sync,dirsync,dfltuid=1001,dfltgid=1001,access=user,msize=65536,trans=tcp,version=9p2000.u,port=41323)

$ df /data/mount
Filesystem     1K-blocks  Used Available Use% Mounted on
192.168.99.1           0     0         0    - /data/mount

[afbjorklund]

It seems our 9p server simply doesn't implement the needed "statfs" call.

https://github.com/kubernetes/minikube/tree/master/third_party/go9p/

It seems to be a 9p2000.L feature

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[john-tipper]

/remove-lifecycle rotten

[john-tipper]

/remove-lifecycle stale

[tstromberg]

The clearest way to resolve this would be to implement #4324

[medyagh]

closing this in favor of #4324