Re: [syzbot] [hfs?] WARNING in hfs_write_inode

[Finn Thain <fthain@linux-m68k.org>]

On Fri, 21 Jul 2023, Dave Chinner wrote:

> > I suspect that this is one of those catch-22 situations: distros are 
> > going to enable every feature under the sun. That doesn't mean that 
> > anyone is actually _using_ them these days.

I think the value of filesystem code is not just a question of how often 
it gets executed -- it's also about retaining access to the data collected 
in archives, museums, galleries etc. that is inevitably held in old 
formats.

> 
> We need to much more proactive about dropping support for unmaintained 
> filesystems that nobody is ever fixing despite the constant stream of 
> corruption- and deadlock- related bugs reported against them.
> 

IMO, a stream of bug reports is not a reason to remove code (it's a reason 
to revert some commits).

Anyway, that stream of bugs presumably flows from the unstable kernel API, 
which is inherently high-maintenance. It seems that a stable API could be 
more appropriate for any filesystem for which the on-disk format is fixed 
(by old media, by unmaintained FLOSS implementations or abandoned 
proprietary implementations).

Being in userspace, I suppose FUSE could be a stable API though I imagine 
it's not ideal in the sense that migrating kernel code there would be 
difficult. Maybe userspace NFS 4 would be a better fit? (I've no idea, I'm 
out of my depth in /fs...)

Ideally, kernel-to-userspace code migration would be done with automatic 
program transformation -- otherwise it would become another stream of 
bugs.