etcfs: fuse passthrough #331
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
adds fuse passthrough support to etcfs https://docs.kernel.org/6.16/filesystems/fuse-passthrough.html
checks for
ETCFS_ENABLE_PASSTHROUGHenv var to be1oryesto enable. it will fail to enable if the kernel does not support it, even if the env var is set.requires a kernel 6.9+ compiled with FUSE_CAP_PASSTHROUGH (enabled by default)
i think it should come disabled out of the box, in case of possible bugs. i think that the changes to the non-passthrough paths are non-invasive enough that this feels safe.
what does fuse passthrough do:
in "traditional" fuse, on m_open/m_create, when interacting with an existing underlying filesystem, we open the fd, and then when m_read/m_write fuse callback is called, we read/write from said fd. this comes with the unfortunate side effect of forcing user-kernel space copies and context switches.
instead, with fuse passthrough, we can use ioctl to register the fd we open in m_open/m_crate with the kernel and obtain a "backing_id". this "backing_id", when added to the fuse id, allows fuse to skip the call to m_read/m_write, and "passthrough" the call to read/write directly to the fd registered with the backing id, thereby circumventing the requirement to cross user-kernel barrier
the consequences for etcfs are as follows:
limited benchmarks on my machine come back with these results. take these with a grain of salt. it is some ai generated python slop that i used to make the benchmark. i get varying results every time i run it, but it is always positive at least on my machine so far.
(14900@5.8ghz, btrfs on nvme, debian 13 kernel 6.12.48)