Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Where is fuse going? API cleanup, restructuring and more

["Darrick J. Wong" <djwong@kernel.org>]

On Sat, Feb 21, 2026 at 01:07:55AM -0500, Demi Marie Obenour wrote:
> On 2/6/26 01:09, Darrick J. Wong wrote:
> > On Wed, Feb 04, 2026 at 11:43:05AM +0100, Jan Kara wrote:
> >> On Wed 04-02-26 01:22:02, Joanne Koong wrote:
> >>> On Mon, Feb 2, 2026 at 11:55 PM Miklos Szeredi <miklos@szeredi.hu> wrote:
> >>>>> I think that at least one question of interest to the wider fs audience is
> >>>>>
> >>>>> Can any of the above improvements be used to help phase out some
> >>>>> of the old under maintained fs and reduce the burden on vfs maintainers?
> >>>
> >>> I think it might be helpful to know ahead of time where the main
> >>> hesitation lies. Is it performance? Maybe it'd be helpful if before
> >>> May there was a prototype converting a simpler filesystem (Darrick and
> >>> I were musing about fat maybe being a good one) and getting a sense of
> >>> what the delta is between the native kernel implementation and a
> >>> fuse-based version? In the past year fuse added a lot of new
> >>> capabilities that improved performance by quite a bit so I'm curious
> >>> to see where the delta now lies. Or maybe the hesitation is something
> >>> else entirely, in which case that's probably a conversation better
> >>> left for May.
> >>
> >> I'm not sure which filesystems Amir had exactly in mind but in my opinion
> >> FAT is used widely enough to not be a primary target of this effort. It
> > 
> > OTOH the ESP and USB sticks needn't be high performance.  <shrug>
> 
> Yup.  Also USB sticks are not trusted.
> 
> >> would be rather filesystems like (random selection) bfs, adfs, vboxfs,
> >> minix, efs, freevxfs, etc. The user base of these is very small, testing is
> >> minimal if possible at all, and thus the value of keeping these in the
> >> kernel vs the effort they add to infrastructure changes (like folio
> >> conversions, iomap conversion, ...) is not very favorable.
> > 
> > But yeah, these ones in the long tail are probably good targets.  Though
> > I think willy pointed out that the biggest barrier in his fs folio
> > conversions was that many of them aren't testable (e.g. lack mkfs or
> > fsck tools) which makes a legacy pivot that much harder.
> 
> Does it make sense to keep these filesystems around?  If all one cares
> about is getting the data off of the filesystem, libguestfs with an
> old kernel is sufficient.  If the VFS changes introduced bugs, an old
> kernel might even be more reliable.  If there is a way to make sure
> the FUSE port works, that would be great.  However, if there is no
> way to test them, then maybe they should just be dropped.
> 
> >> For these the biggest problem IMO is actually finding someone willing to
> >> invest into doing (and testing) the conversion. I don't think there are
> >> severe technical obstacles for most of them.
> > 
> > Yep, that's the biggest hurdle -- convincing managers to pay for a bunch
> > of really old filesystems that are no longer mainstream.
> 
> Could libguestfs with old guest kernels be a sufficient replacement?
> It's not going to be fast, but it's enough for data preservation.

In principle it might work, though I have questions about the quality of
whatever's internally driving guestmount.

Do you know how exactly libguestfs/guestmount accesses (say) an XFS
filesystem?  I'm curious because libxfs isn't a shared library, so
either it would have to manipulate xfs_db (ugh!), run the kernel in a VM
layer, or ... do they have their own implementation ala grub?

--D

> libguestfs supports "fixed appliances", which allow using whatever
> kernel one wants.  They even provide some as precompiled binaries.
> -- 
> Sincerely,
> Demi Marie Obenour (she/her/hers)