On 11/19/25 16:51, Gao Xiang wrote: > 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.
Extent metadata shouldn't be a problem, as that is already available during reads and written asynchronously for writes. The headers are awkward, though, and might need some special-casing. > - 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 This is probably an anti-pattern in general, as I expect it precludes the use of inline encryption hardware via blk-crypto. -- Sincerely, Demi Marie Obenour (she/her/hers)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
