9p mount fails with >650 files in a directory: 'too small read size for dir entry' ecode 22

[hanks]

Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT

Minikube version (use minikube version): v0.21.0
Environment:

• OS (e.g. from /etc/os-release): macOS 10.12.5
• VM Driver (e.g. cat ~/.minikube/machines/minikube/config.json | grep DriverName): virtualbox 5.1.8 r111374
• ISO version (e.g. cat ~/.minikube/machines/minikube/config.json | grep -i ISO or minikube ssh cat /etc/VERSION): minikube-v0.23.0.iso
• Install tools:
• Others:

What happened:
I use the new flag minikube mount --msize 104857600, and I tried some values from the default value 262144(256KB) to 104857600(100MB), still can not mount the alembic versions directory, that contains about total 644 (same filename with different ext, .py and .pyc) files, and filename length is average 30 character.

But when I remove all the .pyc files to reduce the total file number to 322, it can be mounted.

Debug log is below:

sudo mount -t 9p -o trans=tcp,port=55116,dfltuid=1001,dfltgid=1001,version=9p2000.u,msize=104857600 192.168.99.1 /xxxx/alembic/versions;

2017/07/26 12:44:06 <<< 192.168.99.106:48318 Rstat tag 1 st ('versions' 'none' 'none' 'none' q (7cf86b 7ce03230 'd') m d755 at 0 mt 1501038654 l 21964 t 0 d 0 ext )
2017/07/26 12:44:06 >>> 192.168.99.106:48318 Tread tag 1 fid 5 offset 0 count 65512
2017/07/26 12:44:06 <<< 192.168.99.106:48318 Rread tag 1 count 65428
2017/07/26 12:44:06 >>> 192.168.99.106:48318 Tread tag 1 fid 5 offset 65428 count 84
2017/07/26 12:44:06 <<< 192.168.99.106:48318 Rerror tag 1 ename 'too small read size for dir entry' ecode 22
2017/07/26 12:44:06 >>> 192.168.99.106:48318 Tclunk tag 1 fid 5

What you expected to happen:
Directory should be mounted

How to reproduce it (as minimally and precisely as possible):

Anything else do we need to know:

[davefinster]

I'm encountering something similar with a node_modules folder containing 912 individual folders. For me, I just get an empty directory. When running minikube mount with -v 10 I get the following entries:

2017/09/26 14:05:24 >>> 192.168.99.100:59698 Tstat tag 1 fid 3
2017/09/26 14:05:24 <<< 192.168.99.100:59698 Rstat tag 1 st ('node_modules' 'none' 'none' 'none' q (2006205e9 bb3fb888 'd') m d755 at 0 mt 1506380069 l 29280 t 0 d 0 ext )
2017/09/26 14:05:24 >>> 192.168.99.100:59698 Twalk tag 1 fid 3 newfid 4
2017/09/26 14:05:24 <<< 192.168.99.100:59698 Rwalk tag 1
2017/09/26 14:05:24 >>> 192.168.99.100:59698 Topen tag 1 fid 4 mode 0
2017/09/26 14:05:24 <<< 192.168.99.100:59698 Ropen tag 1 qid (2006205e9 bb3fb888 'd') iounit 0
2017/09/26 14:05:24 >>> 192.168.99.100:59698 Tread tag 1 fid 4 offset 0 count 65512
2017/09/26 14:05:24 <<< 192.168.99.100:59698 Rread tag 1 count 65508
2017/09/26 14:05:24 >>> 192.168.99.100:59698 Tread tag 1 fid 4 offset 65508 count 4
2017/09/26 14:05:24 <<< 192.168.99.100:59698 Rerror tag 1 ename 'too small read size for dir entry' ecode 22
2017/09/26 14:05:24 >>> 192.168.99.100:59698 Tclunk tag 1 fid 4
2017/09/26 14:05:24 <<< 192.168.99.100:59698 Rclunk tag 1

Oddly it appears that only directory listing is affected. If I attempt to go directly to a particular path, it succeeds. This is with the following:

minikube version: v0.22.2
OS: macOS High Sierra Gold Master - 10.13 (17A362a)
Driver: Virtualbox
ISO: minikube-v0.23.4.iso

I have gone as high as using this:

minikube mount --msize=1004857600 -v 10 $(pwd):/mnt/Projects

[amnk]

I'm facing the same behavior with node_modules folder (797 directories in it). Tries setting msize to the biggest possible value, but still get this.

minikube mount --msize=1048576000 --v 10 node_modules/:/node_modules

[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
/remove-lifecycle stale

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

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

[Diggsey]

/reopen
/remove-lifecycle rotten

AFAICT, this makes minikube completely unusable with npm??

[k8s-ci-robot]

@Diggsey: you can't re-open an issue/PR unless you authored it or you are assigned to it.

In response to this:

/reopen
/remove-lifecycle rotten

AFAICT, this makes minikube completely unusable with npm??

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.