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 05:16:25PM -0500, Demi Marie Obenour wrote:
> On 2/21/26 02:07, Darrick J. Wong wrote:
> > 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?
> 
> They run Linux in a VM.  Using an old Linux would allow working with
> old filesystems that have since been removed.  If KVM is available,
> the VM is (or at least should be) strongly sandboxed.

/me tries out libguestfs and ... wow it's slow to start.  It does seem
to provide the isolation of the fs parsing code that I want, but the
overheads are quite high.  500MB memory to mount a totally empty XFS
filesystem, and 350MB of disk space to create a rootfs, ouch.

--D

> -- 
> Sincerely,
> Demi Marie Obenour (she/her/hers)