Message-ID: <2baf2118-c0aa-43da-8fc7-0047fc31023f@linux.alibaba.com>
Date: Thu, 20 Nov 2025 09:49:55 +0800
From: Gao Xiang <hsiangkao@...ux.alibaba.com>
To: Demi Marie Obenour <demiobenour@...il.com>,
 "Darrick J. Wong" <djwong@...nel.org>
Cc: bernd@...ernd.com, joannelkoong@...il.com, linux-ext4@...r.kernel.org,
 linux-fsdevel@...r.kernel.org, miklos@...redi.hu, neal@...pa.dev,
 linux-bcachefs@...r.kernel.org, linux-btrfs@...r.kernel.org,
 zfs-devel@...t.zfsonlinux.org
Subject: Re: [PATCHSET v6 4/8] fuse: allow servers to use iomap for better
 file IO performance



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

Powered by blists - more mailing lists