On 9/10/23 10:19, Geert Uytterhoeven wrote:
Hi Kent,
On Sun, Sep 10, 2023 at 12:42 AM Kent Overstreet
<kent.overstreet@xxxxxxxxx> 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.
