linux-ext4 - Re: [RFC[RAP]] 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: <20250701060255.GG9987@frogsfrogsfrogs>
Date: Mon, 30 Jun 2025 23:02:55 -0700
From: "Darrick J. Wong" <djwong@...nel.org>
To: Bernd Schubert <bernd@...ernd.com>
Cc: Allison Karlitskaya <lis@...hat.com>, Theodore Ts'o <tytso@....edu>,
	Amir Goldstein <amir73il@...il.com>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>, John@...ves.net,
	miklos@...redi.hu, joannelkoong@...il.com,
	Josef Bacik <josef@...icpanda.com>,
	linux-ext4 <linux-ext4@...r.kernel.org>
Subject: Re: [RFC[RAP]] fuse: use fs-iomap for better performance so we can
 containerize ext4

On Fri, Jun 20, 2025 at 01:50:20PM +0200, Bernd Schubert wrote:
> 
> 
> On 6/20/25 10:58, Allison Karlitskaya wrote:
> > hi Ted,
> > 
> > Sorry I didn't see this earlier.  I've been travelling.
> > 
> > On Wed, 11 Jun 2025 at 21:25, Theodore Ts'o <tytso@....edu> wrote:
> > > This may break the github actions for composefs-rs[1], but I'm going
> > > to assume that they can figure out a way to transition to Fuse3
> > > (hopefully by just using a newer version of Ubuntu, but I suppose it's
> > > possible that Rust bindings only exist for Fuse2, and not Fuse3).  But
> > > in any case, I don't think it makes sense to hold back fuse2fs
> > > development just for the sake of Ubuntu Focal (LTS 20.04).  And if
> > > necessary, composefs-rs can just stay back on e2fsprogs 1.47.N until
> > > they can get off of Fuse2 and/or Ubuntu 20.04.  Allison, does that
> > > sound fair to you?
> > 
> > To be honest, with a composefs-rs hat on, I don't care at all about
> > fuse support for ext2/3/4 (although I think it's cool that it exists).
> > We also use fuse in composefs-rs for unrelated reasons, but even there
> > we use the fuser rust crate which has a "pure rust" direct syscall
> > layer that no longer depends on libfuse.  Our use of e2fsprogs is
> > strictly related to building testing images in CI, and for that we
> > only use mkfs.ext4.  There's also no specific reason that we're using
> > old Ubuntu.  I probably just copy-pasted it from another project
> > without paying too much attention.
> 
> 
> From libfuse point of view I'm too happy about that split into different

"too happy"?  I would have thought you would /not/ be too happy about
splits... <confused>

> libraries. Libfuse already right now misses several features because
> they were added to virtiofs, but not to libfuse. I need to find the time
> for it, but I guess it makes sense to add rust support to libfuse (and
> some parts can be entirely rewritten into rust).

Yeah, I noticed a few missing pieces like statx and syncfs support,
which I added to my own libfuse branch (+ fuse2fs).  Eventually I'd like
to get the kernel umount code to flush and wait for all pending fuse
commands, issue a FUSE_SYNCFS and wait for that, and then issue a
FUSE_DESTROY to tell the fuse server to tear itself down and release the
block devices(s) its holding.

--D

> 
> 
> Thanks,
> Bernd
>