Re: [syzbot] [hfs?] WARNING in hfs_write_inode
Finn Thain <[email protected]> Fri, 21 Jul 2023 11:03:28 +1000 (AEST)
| Newsgroups | gmane.linux.debian.ports.alpha |
|---|---|
| Message-ID | <60b57ae9-ff49-de1d-d40d-172c9e6d43d5__21864.1479661287$1689902522$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.