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

[Demi Marie Obenour <demiobenour@gmail.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 3153 bytes --]

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.

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)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]