On Wed, 2023-09-06 at 00:23 +0100, Matthew Wilcox wrote:
> On Wed, Sep 06, 2023 at 09:06:21AM +1000, Dave Chinner wrote:
[...]
> > > E.g. the hfsplus driver is unmaintained despite collecting odd
> > > fixes. It collects odd fixes because it is really useful for
> > > interoperating with MacOS and it would be a pity to remove it.
> > > At the same time it is impossible to test changes to hfsplus
> > > sanely as there is no mkfs.hfsplus or fsck.hfsplus available for
> > > Linux. We used to have one that was ported from the open source
> > > Darwin code drops, and I managed to get xfstests to run on
> > > hfsplus with them, but this old version doesn't compile on any
> > > modern Linux distribution and new versions of the code aren't
> > > trivially portable to Linux.
> > >
> > > Do we have volunteers with old enough distros that we can list as
> > > testers for this code? Do we have any other way to proceed?
> > >
> > > If we don't, are we just going to untested API changes to these
> > > code bases, or keep the old APIs around forever?
> >
> > We do slowly remove device drivers and platforms as the hardware,
> > developers and users disappear. We do also just change driver APIs
> > in device drivers for hardware that no-one is actually able to
> > test. The assumption is that if it gets broken during API changes,
> > someone who needs it to work will fix it and send patches.
> >
> > That seems to be the historical model for removing unused/obsolete
> > code from the kernel, so why should we treat unmaintained/obsolete
> > filesystems any differently? i.e. Just change the API, mark it
> > CONFIG_BROKEN until someone comes along and starts fixing it...
>
> Umm. If I change ->write_begin and ->write_end to take a folio,
> convert only the filesystems I can test via Luis' kdevops and mark
> the rest as CONFIG_BROKEN, I can guarantee you that Linus will reject
> that pull request.
I think really everyone in this debate needs to recognize two things:
1. There are older systems out there that have an active group of
maintainers and which depend on some of these older filesystems
2. Data image archives will ipso facto be in older formats and
preserving access to them is a historical necessity.
So the problem of what to do with older, less well maintained,
filesystems isn't one that can be solved by simply deleting them and we
have to figure out a way to move forward supporting them (obviously for
some value of the word "support").
By the way, people who think virtualization is the answer to this
should remember that virtual hardware is evolving just as fast as
physical hardware.
> I really feel we're between a rock and a hard place with our
> unmaintained filesystems. They have users who care passionately, but
> not the ability to maintain them.
So why is everybody making this a hard either or? The volunteer
communities that grow around older things like filesystems are going to
be enthusiastic, but not really acquainted with the technical
intricacies of the modern VFS and mm. Requiring that they cope with all
the new stuff like iomap and folios is building an unbridgeable chasm
they're never going to cross. Give them an easier way and they might
get there.
So why can't we figure out that easier way? What's wrong with trying to
figure out if we can do some sort of helper or library set that assists
supporting and porting older filesystems. If we can do that it will not
only make the job of an old fs maintainer a lot easier, but it might
just provide the stepping stones we need to encourage more people climb
up into the modern VFS world.
I'd like to propose that we add to this topic discussion of mechanisms
by which we assist people taking on older filesystems to fit into the
modern world.
James
