Re: [PATCHSET v6 4/8] fuse: allow servers to use iomap for better file IO performance

[Demi Marie Obenour <demiobenour@gmail.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 2644 bytes --]

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.
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.

> 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!
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]