On Sun, Sep 10, 2023 at 10:19:30AM +0200, 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? This would be for the filesystems that aren't getting maintained and tested, to eliminate accidental breakage from in-kernel refactoring and changing of APIs. Getting that code out of the kernel would also greatly help with security concerns.
