Sweet Tea,
Can you please explain the workload where you find that this patch is needed?
I was researching before sending out my own version of attr passthrough
- it seemed like a step in the direction, but then the code in-tree
wasn't the same.
Is your workload using mmap writes? requires a long attribute cache timeout?
Does your workload involve mixing passthrough IO and direct/cached IO
on the same inode at different times or by different open fd's?
I would like to know, so I can tell you if getattr() passthrough design is
going to help your use case.
For example, my current getattr() passthrough design (in my head)
will not allow opening the inode in cached IO mode from lookup time
until evict/forget, unlike the current read/write passthrough, which is
from first open to last close.
I think the things I'd been working on is very similar.
Two possible HSM variants, both focused on doing passthrough IO with
minimal involvement from the fuse server in at least some cases.
One would be using passthrough for temporary ingestion of some memory
state for a workload, user writes files and the FUSE server can choose
to passthrough them to local storage temporarily or to send them to
remote storage -- as ingestion requires pausing the workload and is
therefore very expensive, I'd like to pass through attr updates to the
backing file so that there are minimal roundtrips to the fuse server
during write. Later the HSM would move the files to remote storage, or
delete them.
One would be using passthrough for binaries -- providing specific sets
of mostly binaries with some tracking on open/close, so the HSM can
delete unused sets. Again the goal is to avoid metadata query roundtrips
to userspace for speed; we don't expect a file open in passthrough mode
to be opened again for FUSE-server-mediated IO until the passthrough
version is closed.
Thanks!
Sweet Tea
