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

Finn Thain <[email protected]>
Newsgroups gmane.linux.debian.ports.amd64
Message-ID <60b57ae9-ff49-de1d-d40d-172c9e6d43d5__36094.3804889516$1689902503$gmane$org@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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.