File open error for storage mounted with subdirectory and block cache. #1612
Comments
|
The file "somefile.bin" which you are invoking is inside the "somefolder" or outside. |
|
This is all inside a corporate tenant, so I can't share any of the specific details here. Storage file structure [updated with subdirectory]: some_storage_account/
└── some_container
└── some_subdirectory
├── some_file.bin # file open fails
└── some_file2.bin # file open succeeds
another_storage_account/
└── another_container
└── another_subdirectory
├── another_file.bin # file open succeeds
└── another_file2.bin # file open failAgain:
|
|
Shared logs are incomplete. |
|
Pasting redacted log below, please look for |
|
According to the logs, the operation on myfileopensuccess.bin was successful. |
|
|
@listcrawler Could you please try with the latest release? Your logs do not match with the directory structure, and there is no processing at azstorage level. Looks like things are served from cache. |
|
Have you verified this is WSL2? |
|
@listcrawler yes, verified everything with WSL2. |
|
Right, then returning to your questions:
Not really my jurisdiction, but the first step in the error path mentioned in my first post, holds the immediate question: Why does attr_cache.go:482 say "served from cache" and then return a ENOENT which leads to general failure? Guessing wildly here, but wouldn't the right thing to do, to try the next component? |
|
This scenario occurs only if your directory name and filename are same. |
|
Briefly looking through the description of the linked bug, there may be more to this problem. We don't really have the same name of a directory and a file. Maybe, if you removed file suffixes, there could be name clash, but we see this for all kinds of filenames. Again, by turning blobfuse features on and off, it rather seems to be related to block/file cache, subdirectory option and flat/hierarchic storage. |
|
@listcrawler,
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When mounting a storage subdirectory with a block cache, opening of files may fail. Using a file cache or without a subdirectory shows no such problems.
Inside the directory, some files can be opened and others not, seemingly arbitrarily. The success and failures are consistent across remounts though. The storage has a flat namespace and block blobs.
From what I can discern, the failing code path is like this:
config.yaml:
Invoking blobfuse2 with
--subdirectory=somefolderthen may exhibit this failure. Not passing the subdirectory option or using a file cache seems to work well.This was all done in wsl2.
The text was updated successfully, but these errors were encountered: