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: <20250701055847.GF9987@frogsfrogsfrogs>
Date: Mon, 30 Jun 2025 22:58:47 -0700
From: "Darrick J. Wong" <djwong@...nel.org>
To: Allison Karlitskaya <lis@...hat.com>
Cc: Theodore Ts'o <tytso@....edu>, Amir Goldstein <amir73il@...il.com>,
	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>
Subject: Re: [RFC[RAP]] fuse: use fs-iomap for better performance so we can
 containerize ext4

On Fri, Jun 20, 2025 at 10:58:38AM +0200, 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

Aha, I just stumbled upon that crate.  There are ... too many things on
crates.io that claim to be fuse libraries/wrappers/etc.

It's tempting to go write fuse4fs as a iomap-only Rust server, but I
never quite got the hang of configuring cargo to link against a locally
built .so in the same source tree (i.e. when I was trying to link
xfs_healer against libhandle that ships as part of xfsprogs).  I'm not
even sure I want to explore exposing libext2fs in a Rust-safe way.

> 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.
> 
> Thanks for asking, though!

I'm glad to hear that e2fsprogs can drop fuse2 support! :)

--D

> lis
> 
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ