Open nbdd0121 opened 2 months ago
Thanks @nbdd0121 for reaching out. This is a known limitation at this point that the file cache is not persistent across mounts.
The documentation could have been more clearer here. It actually tries to say the file cache will be re-used for subsequent operations once the metadata cache is filled. It assumes that file cache is also filled in the current session. The lines together with the previous line is what might be misleading. Will work with the documentation team to change this appropriately.
The reason for the limitation right now is the file cache doesn't hold a marker of the generation(version) of the object on the disk ( which the metadata cache holds). There's no way to reconcile if the local file (cached already) and the new metadata (filled in the new mount session) are the same without additional changes. This is a roadmap item in the future but no timelines at this point.
cc @marcoa6
Describe the issue
When GCSFuse unmounts and remounts, the file cache populated doesn't seem to be accessed.
n https://cloud.google.com/storage/docs/gcsfuse-cache#persistence says that the file cache should be reused when the metadata cache has been populated, but it doesn't seem to be the case.
A brief grep through the codebase suggests that contentcache have the code that handles persistence of the cache, but this functionality is not present in the filecache code. The contentcache seems completely unused currently so the functionality is lost.
Reproduction
The following experiment is conducted:
gcsfuse -o ro --file-mode=755 --config-file=gcs.yaml BUCKET_NAME /mnt
with the config file below:vmtouch -t /mnt/large_file
takes ~18 seconds.umount /mnt
and remount.vmtouch -t /mnt/large_file
still takes ~18 seconds.System (please complete the following information):
Additional context Add any other context about the problem here.
SLO: We strive to respond to all bug reports within 24 business hours.