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

["Theodore Ts'o" <tytso@mit.edu>]

+Allison Karlitskaya

On Tue, Jun 10, 2025 at 12:00:26PM -0700, Darrick J. Wong wrote:
> > High level fuse interface is not the right tool for the job.
> > It's not even the easiest way to have written fuse2fs in the first place.
> 
> At the time I thought it would minimize friction across multiple
> operating systems' fuse implementations.
> 
> > High-level fuse API addresses file system objects with full paths.
> > This is good for writing simple virtual filesystems, but it is not the
> > correct nor is the easiest choice to write a userspace driver for ext4.
> 
> Agreed, it's a *terrible* way to implement ext4.
> 
> I think, however, that Ted would like to maintain compatibility with
> macfuse and freebsd(?) so he's been resistant to rewriting the entire
> program to work with the lowlevel library.

My priority is to make sure that we have compatibility with other OS's
(in particular MacOS, FreeBSD, if possible Windows, although that's
not something that I develop against or have test vehicles to
validate).  However, from what I can tell, they all support Fuse3 at
this point --- MacFuse, FreeBSD, and WinFSP all have Fuse3 support as
of today.

The only complaint that I've had about breaking support using Fuse2
was from Allison (Cc'ed), who was involved with another Github
project, whose Github Actions break because they were using a very old
version of Ubuntu LTS 20.04), which only had support for libfuse2.  I
am going to assume that this is probably only because they hadn't
bothered to update their .github/workflows/ci.yaml file, and not
because there was any inherit requirement that we support ancient
versions of Linux distributions.  (When I was at IBM, I remember
having to support customers who used RHEL4, and even in one extreme
case, RHEL3 because there were a customer paying $$$$$ that refused to
update; but that was well over a decade ago, and at this point, I'm
finding it a lot harder to care about that.  :-)

My plan is that after I release 1.47.2 (which will have some
interesting data corruption bugfixes thanks to Darrick and other users
using fuse2fs in deadly earnest, as opposed to as a lightweight way to
copy files in and out of an file system image), I plan to transition
the master and next branches for the future 1.48 release, and the
maint branch will have bug fixes for 1.47.N releases.

At that point, unless I hear some very strong arguments against, for
1.48, my current thinking is that we will drop support for Fuse2.  I
will still care about making sure that fuse2fs will build and work
well enough that casual file copies work on MacOS and FreeBSD, and
I'll accept patches that make fuse2fs work with WinFSP.  In practice,
this means that Linux-specific things like Verity support will need to
be #ifdef'ed so that they will build against MacFUSE, and I assume the
same will be true for fuseblk mode and iomap mode(?).

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?

[1] https://github.com/containers/composefs-rs

Does anyone else have any objections to dropping Fuse2 support?  And
is that sufficient for folks to more easily support iomap mode in
fuse2fs?

Cheers,

							- Ted

P.S.  Greetings from Greenland.  :-)  (We're currently in the middle of
a cruise that started in Iceland, and will be ending in New York City
next week.)