Minikube mount fails with "Unknown error 526" #1562
Comments
cu12
changed the title
Unknown error 526
|
I'm running into the same issue on Windows 10, using Hyper-V. Environment:
Steps to reproduce: In the repo, there are two branches ( There appears to be a relationship between the number of files, length of the filenames, and the size on disk. For example, if I shortened the filename lengths I would need more files in order to produce the same error, despite the fact that they took more total disk space. This makes me think that there's some sort of relationship between the size of the folder contents and the size of them represented on disk. i.e: Passing Scenario:
Broken Scenario:
For reference, it appears that the error is being emitted from go9p/ufs.go#L384. The key section being: if count == 0 && int(tc.Offset) < len(fid.dirents) && len(fid.dirents) > 0 {
req.RespondError(&Error{"too small read size for dir entry", EINVAL})
return
} |
|
Thank you very much for the detailed bug report. The examples in the github repo were really useful in testing this. This 9p ufs implementation is adapted from https://github.com/rminnich/go9p/ with some small tweaks for cross-platform support. So bear with me as I will need to read over this. The tests below involve running The failure condition for this the failing branch appears to be going through: This 3rd nested if statement, and then hitting the error you mentioned above: A gist of some debug output for the failing case is here: It seems that an initial read is performed for the directory In the successful case, the flow is: The first nested if statement (but none of the nested if statements trigger): A gist of some debug output for the successful case is here: From the implementation it seems that this error condition is designed to catch when the tc.Offset smaller than fid.dirents. fid.dirents is byte[] where each entry in the list is a single character and the whole e list contains all of the filenames concatinated with some metadata: This value grows as you put more files/longer-file-names in a directory. tc.Offset (and tc.Count) seem to be a parameters that are passed into the call and as such cannot be modified to be "larger". From investigating the code it seems that it is possible that when this statement is triggered: |
|
There's actually a flag option for 9p with mount, msize, that can change the message size allowable for mount. Configuring this flag should allow you to use arbitrary sized/named directories. The PR for this is here, you can use it with |
|
I am running into this too. Minikube version: v0.20.0 I have a directory with 121 files in it, and it shows as empty with error 526. If I delete all the files and create empty files one by one, I can see the error is caused at exactly 102 files (ie: I can So strange! I'm glad you've already fixed it and I'm looking forward to the next release! |
|
Would this be able to make it into a v0.20.1 release? |
|
@veqryn I think we're planning a release today |
|
This should be fixed with #1705. Closing. |
|
Hello everybody, I'm running into this on Regards! |
Is this a BUG REPORT or FEATURE REQUEST? (choose one):
Minikube version (use
minikube version):Environment:
cat ~/.minikube/machines/minikube/config.json | grep DriverName): virtualboxcat ~/.minikube/machines/minikube/config.json | grep -i ISOorminikube ssh cat /etc/VERSION): minikube-v0.18.0.isoWhat happened:
Mounted a directory with gazillions of folders/files (69893/315668)
minikube mount ../:/srcWhat you expected to happen:
Files to be listed, but got
How to reproduce it (as minimally and precisely as possible):
Not sure yet, but I guess it has to do something with the amount of files and directories as mounting a simple directory inside the structure works fine.
Anything else do we need to know:
mount part of
--v=10the error:
The text was updated successfully, but these errors were encountered: