On Sat, May 28, 2022 at 10:02:16AM +1000, Dave Chinner wrote:
> On Thu, May 26, 2022 at 08:29:01PM +0100, Matthew Wilcox (Oracle) wrote:
> > This patchset does not work. It will eat your filesystem. Do not apply.
> >
> > The bug starts to show up with the fourth patch ("Convert direct_IO write
> > support to use iomap"). generic/013 creates a corrupt filesystem and
> > fsck fails to fix it, which shows all kinds of fun places in xfstests
> > where we neglect to check that 'mount' actually mounted the filesystem.
> > set -x or die.
> >
> > I'm hoping one of the people who knows iomap better than I do can just
> > point at the bug and say "Duh, it doesn't work like that".
> >
> > It's safe to say that every patch after patch 6 is untested. I'm not
> > convinced that I really tested patch 6 either.
>
> So the question I have to ask here is "why even bother?".
>
> JFS is a legacy filesystem, and the risk of breaking stuff or
> corrupting data and nobody noticing is really quite high.
>
> We recently deprecated reiserfs and scheduled it's removal because
> of the burden of keeping it up to date with VFS changes, what makes
> JFS any different in this regard?
Deprecating and scheduling removal is all well and good (and yes,
we should probably have a serious conversation about when we should
remove JFS), but JFS is one of the two users of the nobh infrastructure.
If we want to get rid of the nobh infrastructure (which I do), we need
to transition JFS to some other infrastructure.
We also need to convert more filesystems to use iomap. I really wanted
to NAK the ntfs3 submission on the basis that it was still BH based,
but with so many existing filesystems using the BH infrastructure,
that's not a credible thing to require.
So JFS stood out to me as a filesystem which uses infrastructure that we
can remove fairly easily, one which doesn't get a whole lot of patches,
one that doesn't really use a lot of the BH infrastructure anyway and
one which can serve as an example for more ... relevant filesystems.
