linux-ext4 - [RFC[RAP] V2] fuse: use fs-iomap for better performance so we can containerize ext4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250613173710.GL6138@frogsfrogsfrogs>
Date: Fri, 13 Jun 2025 10:37:10 -0700
From: "Darrick J. Wong" <djwong@...nel.org>
To: Amir Goldstein <amir73il@...il.com>
Cc: linux-fsdevel <linux-fsdevel@...r.kernel.org>, John@...ves.net,
	bernd@...ernd.com, miklos@...redi.hu, joannelkoong@...il.com,
	Josef Bacik <josef@...icpanda.com>,
	linux-ext4 <linux-ext4@...r.kernel.org>,
	Theodore Ts'o <tytso@....edu>, Matthew Wilcox <willy@...radead.org>
Subject: [RFC[RAP] V2] fuse: use fs-iomap for better performance so we can
 containerize ext4

On Thu, May 22, 2025 at 06:24:50PM +0200, Amir Goldstein wrote:
> On Thu, May 22, 2025 at 1:58 AM Darrick J. Wong <djwong@...nel.org> wrote:
> >
> > Hi everyone,
> >
> > DO NOT MERGE THIS.

Three weeks later, I've mostly gotten the iomap caching working.  This
is probably most exciting for John, because we were talking earlier
about uploading storage mappings to the fuse driver and this is what
I've come up with.  I'm running around trying to fix all the stuff that
doesn't quite work right.

Top of that list is timestamps and file attributes, because fuse no
longer calls the fuse server for file writes.  As a result, the kernel
inode always has the most uptodate versions of the some file attributes
(i_size, timestamps, mode) and just want to send FUSE_SETATTR whenever
the dirty inode gets flushed.

After I get that working I'm going to have to rewrite fuse2fs (or more
likely just fork it) to be a lowlevel driver because as I've noted
elsewhere in this thread, the upper level fuse library can assign
multiple fuse nodeids for a single hardlinked inode.  The only reason
that worked for non-iomap fuse2fs is because we have a BKL and disable
all caching.

For fuse+iomap, this discrepancy between fuse nodeids and ext2 inumbers
means that iomap just plain doesn't work with hardlinks because there
are multiple struct fuse_inodes for each ondisk inode and the locking is
just broken; and the iomap callouts are per-inode, not per-file which
leads to multiple layering violations in the upper level fuse library.
Also as Amir points out, path lookups on every operation is just *slow*.

Interim branches can be found here:

https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=fuse-iomap-cache_2025-06-13
https://git.kernel.org/pub/scm/linux/kernel/git/djwong/libfuse.git/log/?h=fuse-iomap-cache_2025-06-13
https://git.kernel.org/pub/scm/linux/kernel/git/djwong/e2fsprogs.git/log/?h=fuse2fs-iomap-cache_2025-06-13
https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfstests-dev.git/log/?h=fuse2fs_2025-06-13

(I'm not going to respam the list with patches right now because the
quality as told by fstests isn't quite where I want it to be for such a
thing.  fuse2fs+iomap passes 87% of fstests (down from 89% without
iomap) but that's still pretty bad.)

--D