On 2025/11/20 09:10, Demi Marie Obenour wrote:
On 11/19/25 16:00, Gao Xiang wrote:
On 2025/11/20 02:04, Darrick J. Wong wrote:
On Wed, Nov 19, 2025 at 04:19:36AM -0500, Demi Marie Obenour wrote:
By keeping the I/O path mostly within the kernel, we can dramatically
increase the speed of disk-based filesystems.
ZFS, BTRFS, and bcachefs all support compression, checksumming,
and RAID. ZFS and bcachefs also support encryption, and f2fs and
ext4 support fscrypt.
Will this patchset be able to improve FUSE implementations of these
filesystems? I'd rather not be in the situation where one can have
a FUSE filesystem that is fast, but only if it doesn't support modern
data integrity or security features.
Not on its own, no.
I'm not a filesystem developer, but here are some ideas (that you
can take or leave):
1. Keep the compression, checksumming, and/or encryption in-kernel,
and have userspace tell the kernel what algorithm and/or encryption
key to use. These algorithms are generally well-known and secure
against malicious input. It might be necessary to make an extra
data copy, but ideally that copy could just stay within the
CPU caches.
I think this is easily doable for fscrypt and compression since (IIRC)
the kernel filesystems already know how to transform data for I/O, and
nowadays iomap allows hooking of bios before submission and/or after
endio. Obviously you'd have to store encryption keys in the kernel
somewhere.
I think it depends, since (this way) it tries to reuse some of the
existing kernel filesystem implementations (and assuming the code is
safe), so at least it still needs to load a dedicated kernel module
for such usage at least.
My hope is that these modules could be generic library code.
Actually, the proposed generic library code for compression,
checksumming, and encryption is already in "crypto/", but
except for checksumming usage, filesystems rarely use the
others, mostly because of inflexibility (for example,
algorithms may have case-by-case advanced functionality.)
Compression, checksumming, and encryption algorithms aren't specific
to any particular filesystem, and the kernel might well be using them
already for other purposes.
Of course, it's still the host admin's job to make sure the relevant
modules are loaded, unless they are autoloaded.
My thought is still roughly that, although algorithms could
be generic, the specific implementations are still varied
due to different filesystem on-disk intrinsicness (each
filesystem has its own special trait) and/or whether designs
are made with thoughtful thinking. fscrypt and fsverity are
Linux kernel reference implementations, but, for example,
fsverity metadata representation still takes a while for
XFS folks to discuss (of course it doesn't impact the main
mechanism).
I think it's not an issue for userspace ext4 of course (because ext4
and fscrypt is almost builtin for all kernels), but for out-of-tree
fses even pure userspace fses, I'm not sure it's doable to load the
module in a container context.
Maybe eBPF is useful for this area, but it's still not quite
flexible compared to native kernel filesystems.
Thanks,
Gao Xiang
Thank you for the feedback!
Thanks,
Gao Xiang
