On Wed, Sep 06, 2023 at 12:23:22AM +0100, Matthew Wilcox wrote: > On Wed, Sep 06, 2023 at 09:06:21AM +1000, Dave Chinner wrote: > > > Part 2: unmaintained file systems > > > > > > A lot of our file system drivers are either de facto or formally > > > unmaintained. If we want to move the kernel forward by finishing > > > API transitions (new mount API, buffer_head removal for the I/O path, > > > ->writepage removal, etc) these file systems need to change as well > > > and need some kind of testing. The easiest way forward would be > > > to remove everything that is not fully maintained, but that would > > > remove a lot of useful features. > > > > Linus has explicitly NACKed that approach. > > > > https://lore.kernel.org/linux-fsdevel/CAHk-=wg7DSNsHY6tWc=WLeqDBYtXges_12fFk1c+-No+fZ0xYQ@xxxxxxxxxxxxxx/ > > > > Which is a problem, because historically we've taken code into > > the kernel without requiring a maintainer, or the people who > > maintained the code have moved on, yet we don't have a policy for > > removing code that is slowly bit-rotting to uselessness. > > > > > 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. No, that's not what I was suggesting. I suggest that we -change all the API users when we need to, but in doing so we also need to formalise the fact we do not know if the filesystems nobody can/will maintain function correctly or not. Reflect that with CONFIG_BROKEN or some other mechanism that forces people to acknowledge that the filesystem implementation is not fit for purpose before they attempt to use it. e.g. write some code that emits a log warning about the filesystem being unmaintained at mount time and should not be used in situations where stability, security or data integrity guarantees are required. > 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. Well, yes. IMO, it is even worse to maintain the lie that these unmaintained filesystems actually work correctly. Just because it's part of the kernel it doesn't mean it is functional or that users should be able to trust that it will not lose their data... -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
