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: 3108 bytes --]

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)

[-- 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 --]