Re: [MAINTAINERS/KERNEL SUMMIT] Trust and maintenance of file systems

[Bernd Schubert <bernd.schubert@fastmail.fm>]

On 9/10/23 10:19, Geert Uytterhoeven wrote:
> Hi Kent,
> 
> On Sun, Sep 10, 2023 at 12:42 AM Kent Overstreet
> <kent.overstreet@linux.dev> wrote:
>> On Sat, Sep 09, 2023 at 08:50:39AM -0400, James Bottomley wrote:
>>> So why can't we figure out that easier way? What's wrong with trying to
>>> figure out if we can do some sort of helper or library set that assists
>>> supporting and porting older filesystems. If we can do that it will not
>>> only make the job of an old fs maintainer a lot easier, but it might
>>> just provide the stepping stones we need to encourage more people climb
>>> up into the modern VFS world.
>>
>> What if we could run our existing filesystem code in userspace?
>>
>> bcachefs has a shim layer (like xfs, but more extensive) to run nearly
>> the entire filesystem - about 90% by loc - in userspace.
>>
>> Right now this is used for e.g. userspace fsck, but one of my goals is
>> to have the entire filesystem available as a FUSE filesystem. I'd been
>> planning on doing the fuse port as a straight fuse implementation, but
>> OTOH if we attempted a sh vfs iops/aops/etc. -> fuse shim, then we would
>> have pretty much everything we need to run any existing fs (e.g.
>> reiserfs) as a fuse filesystem.
>>
>> It'd be a nontrivial project with some open questions (e.g. do we have
>> to lift all of bufferheads to userspace?) but it seems worth
>> investigating.
> 
>    1. https://xkcd.com/1200/ (not an exact match, but you should get the idea),
>    2. Once a file system is removed from the kernel, would the user space
>       implementation be maintained better?

Unlikely that it would be maintained any better, more the other way around.
But then, effects on the entire system wouldn't be that severe anymore.
Moving deprecated file systems to fuse had been a short discussion
at LSFMM.