On 9/7/23 04:18, Thorsten Leemhuis wrote:
On 07.09.23 12:29, Christian Brauner wrote:
So why can't that work similarly for unmaintained file systems? We could
even establish the rule that Linus should only apply patches to some
parts of the kernel if the test suite for unmaintained file systems
succeeded without regressions. And only accept new file system code if a
Reading this mail scared me.
Sorry about that, I can fully understand that. It's just that some
statements in this thread sounded a whole lot like "filesystems want to
opt-out of the no regression rule" to me. That's why I at some point
thought I had to speak up.
The list of reiserfs bugs alone is crazy.
Well, we regularly remove drivers or even support for whole archs
without getting into conflict with the "no regressions" rule, so I'd say
that should be possible for file systems as well.
And I think for reiserfs we are on track with that.
But what about hfsplus? From hch's initial mail of this thread it sounds
like that is something users would miss. So removing it without a very
strong need[1] seems wrong to me. That's why I got involved in this
discussion.
The original mail also suggested that there would be essentially no means
to create a hfsplus file system in Linux. That would mean it would, for all
practical purposes, be untestable.
However:
$ sudo apt-get install hfsprogs
$ truncate -s 64M filesystem.hfsplus
$ mkfs.hfsplus filesystem.hfsplus
Initialized filesystem.hfsplus as a 64 MB HFS Plus volume
$ file filesystem.hfsplus
filesystem.hfsplus: Macintosh HFS Extended version 4 data last mounted by: '10.0', created: Thu Sep 7 05:41:21 2023, last modified: Thu Sep 7 12:41:21 2023, last checked: Thu Sep 7 12:41:7
So I am not really sure I understand what the problem actually is.
No a side note, the crash I observed with ntfs3 was introduced by
commit a4f64a300a29 ("ntfs3: free the sbi in ->kill_sb").
Guenter
