On 2025/11/19 17:19, 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.
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
I don't think it's generally feasible unless it's limited to
specific implementations because each transformation-like ondisk
encoded data has its own design, which is unlike raw data.
Although the algorithms are well-known but the ondisk data could
be wrapped up with headers, footers, or specific markers.
I think for the specific fscrypt or fsverity it could be possible
(for example, I'm not sure zfs is 100%-compatible with fscrypt or
fsverity, if they implements similiar stuffs), but considering
generic compression, checksumming, and encryption, filesystem
implementations can do various ways (even in various orders) with
possible additional representations.
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.
Thanks,
Gao Xiang
