On 2025/11/20 05: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.
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.
Two examples for reference:
- For compression, in-tree f2fs already has a compression header
in data of each compressed extent:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/f2fs/f2fs.h?h=v6.17#n1497
while other fs may store additional metadata in extent metadata
or other place.
- gocryptfs (a pure userspace FUSE fs) uses a different format
from fscrypt (encrypted data seems even unaligned on disk):
https://github.com/rfjakob/gocryptfs/blob/master/Documentation/file-format.md
Maybe eBPF is useful for this area, but it's still not quite
flexible compared to native kernel filesystems.
Thanks,
Gao Xiang
