Re: [MAINTAINERS/KERNEL SUMMIT] Trust and maintenance of file systems

Dave Chinner
2023-09-07T03:14:13Z

On Thu, Sep 07, 2023 at 07:53:36AM +0700, Bagas Sanjaya wrote:
> On Thu, Sep 07, 2023 at 08:54:38AM +1000, Dave Chinner wrote:
> > There's a bigger policy question around that.
> >
> > I think that if we are going to have filesystems be "community
> > maintained" because they have no explicit maintainer, we need some
> > kind of standard policy to be applied.
> >
> > I'd argue that the filesystem needs, at minimum, a working mkfs and
> > fsck implementation, and that it is supported by fstests so anyone
> > changing core infrastructure can simply run fstests against the
> > filesystem to smoke test the infrastructure changes they are making.
>
> OK.
>
> >
> > I'd suggest that syzbot coverage of such filesystems is not desired,
> > because nobody is going to be fixing problems related to on-disk
> > format verification. All we really care about is that a user can
> > read and write to the filesystem without trashing anything.
> >
> > I'd also suggest that we mark filesystem support state via fstype
> > flags rather than config options. That way we aren't reliant on
> > distros setting config options correctly to include/indicate the
> > state of the filesystem implementation. We could also use similar
> > flags for indicating deprecation and obsolete state (i.e. pending
> > removal) and have code in the high level mount path issue the
> > relevant warnings.
>
> Something like xfs v4 format?

Kind of, but that's a story of obsolescence, not a lack of
maintenance. For those that don't know the back story, it's below.
For those that do, skip the bit between the '----' lines.

----

We deprecated the v4 XFS on-disk format back in 2020 because it was
superceded by the v5 format that was merged in 2013 (a decade ago).
Since then we have not been adding features to the v4 format because
the v5 format fixes a heap of problems with that old format that
can't otherwise be fixed without changing the on-disk v4 format to
something like the V5 format.

Now throw in the fact that the v4 format is not y2038 compliant.
It's got a hard "end of life" date without putting resources and
effort into an on-disk format change. We aren't going to do that
largely because the V4 format is a development dead end.

Because the v4 format has a hard end of life date, we needed to
have a deprecation plan for the format that was sympathetic to
enterprise distro feature removal policies.

Given that there's usually a 10 year support life from first release
in an enterprise kernel, and typically a 2-3 year lead in cycle,
we're looking at need to have filesystem feature removal occur 10-15
years before the hard end of support date. Further, feature removal
policies required us to mark the feature deprecated for an entire
major before we can remove it in the subsequent release. This means
we needed to make a decision about the V4 format in 2020, a full 18
years before the hard end of life actually occurs.

[ How many people reading this are thinking about what impact a
decision made has on people using that functionality in 10 years
time? This is something filesystem developers have to do all the
time, because the current on-disk format is almost certainly going
to be in use in 10 years time....]

So we deprecated the v4 format upstream, and the enterprise kernels
inherited that in 2020 before the major release went out the door.
That means we can remove support in the next major release, and the
upstream deprecation schedule reflects this - we're turning off v4
support by default in 2025...

We don't want to carry v4 support code forever, so we have a
removal date defined as well. All upstream support for the v4 format
will stop in 2030, and we will remove the relevant code at that
point in time.

Long story short, we recognised that we have obsolete functionality
that we cannot support forever, and we defined and documented the
long term EOL process for to removing support of the obsolete
functionality from the filesystem.

This, however, does not mean the V4 code is unmaintained or
untested; while it is supported it will be tested, though at a
lesser priority than the v5 format code we want everyone to be
using. THe V4 and V5 formats and code share huge amounts of
commonality, so even when we are testing V5 formats we are
exercising almost all the same code that the V4 format uses....

-----

It should be clear at this point that we cannot equate a well
planned removal of obsolescent functionality from a maintained
filesystem with the current situation of kernel being full of
unmaintained filesystem code. The two cases are clearly at opposite
ends of spectrum.

However, we should have similar policies to deal with both
situations. If the filesystem is unmaintained and/or obsolete, we
should have a defined policy and process that leads to it being
either "community maintained" for some period of time and/or
deprecated and removed from the code base.

Look at reiserfs.

The maintainer stepped back and said "I'm happy just to remove the
code from the kernel". It has been unmaintained since.

Rather than pulling the rug out from under any remaining users,
we've marked the filesystem as deprecated (and now obsolete) and
documented a planned removal schedule.

This is the sort of process we need to discuss, formalise and
document - how we go about removing kernel features that are no
longer maintained but may still have a small number of long tail
users with the minimum of disruption to everyone....

-Dave.
--
Dave Chinner
david@fromorbit.com