Message-ID: <39d281ba-1ee4-49ae-9aae-e2bd65342e3f@gmail.com>
Date: Wed, 19 Nov 2025 20:13:58 -0500
From: Demi Marie Obenour <demiobenour@...il.com>
To: Gao Xiang <hsiangkao@...ux.alibaba.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 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)
Download attachment "OpenPGP_0xB288B55FFF9C22C1.asc" of type "application/pgp-keys" (7141 bytes)

Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists