Message-ID: <20220225225600.GO3061737@dread.disaster.area>
Date:   Sat, 26 Feb 2022 09:56:00 +1100
From:   Dave Chinner <david@...morbit.com>
To:     Willy Tarreau <w@....eu>
Cc:     Byron Stanoszek <gandalf@...ds.org>,
        Matthew Wilcox <willy@...radead.org>, Jan Kara <jack@...e.cz>,
        linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        reiserfs-devel@...r.kernel.org
Subject: Re: Is it time to remove reiserfs?

On Fri, Feb 25, 2022 at 02:23:00PM +0100, Willy Tarreau wrote:
> On Fri, Feb 25, 2022 at 08:10:22AM -0500, Byron Stanoszek wrote:
> > On Thu, 24 Feb 2022, Matthew Wilcox wrote:
> > > On Wed, Feb 23, 2022 at 09:48:26AM -0500, Byron Stanoszek wrote:
> > > > For what it's worth, I have a number of production servers still using
> > > > Reiserfs, which I regularly maintain by upgrading to the latest Linux kernel
> > > > annually (mostly to apply security patches). I figured this filesystem would
> > > > still be available for several more years, since it's not quite y2038k yet.
> > > 
> > > Hey Byron, thanks for sharing your usage.
> > > 
> > > It's not entirely clear to me from your message whether you're aware
> > > that our annual LTS release actually puts out new kernels every week (or
> > > sometimes twice a week), and upgrades to the latest version are always
> > > recommended.  Those LTS kernels typically get five years of support in
> > > total; indeed we just retired the v4.4 series earlier this month which
> > > was originally released in January 2016, so it got six years of support.
> > > 
> > > If we dropped reiserfs from the kernel today (and thanks to Edward, we
> > > don't have to), you'd still be able to use a v5.15 based kernel with
> > > regular updates until 2028.  If we drop it in two years, that should
> > > take you through to 2030.  Is that enough for your usage?
> > 
> > I'm aware of the LTS releases, but I hadn't thought about them in relation to
> > this issue. That's a good point, and so it sounds like I have nothing to worry
> > about.
> 
> This just makes me think that instead of speaking about deprecation in
> terms of version, speaking in terms of dates might be more suitable, as
> it should help discouraging distros or products shipping LTS kernels
> from enabling such deprecated features: when you're told the features
> will disappear after, say, 5.20, some might think "OK 5.20 is the last
> one and it happens to be LTS so I get the feature for 6 extra years
> after it's EOL".

This is exactly why the XFS deprecation schedules are dated while
the actual removals record kernel releases. If it gets released in
a kernel, then it technically is supported for the life of that
kernel, even if it is a LTS kernel and the functionality no long
exists upstream.

That is, we know that once we've removed something from upstream,
it's still going to be actively used in LTS kernels based on kernels
that still have that functionality. Same goes for enterprise
kernels. Hence deprecation policies need to first acknowledge the
typical "no regressions" policies for LTS kernels...

With that in mind, this is why we've already deprecated non-y2038k
compliant functionality in XFS so that enterprise kernels can mark
it deprecated in their next major (N + 1) release which will be
supported for 10 years. They can then remove that support it in the
N+2 major release after that (which is probably at least 5 years
down the track) so that the support window for non-compliant
functionality does not run past y2038k.

We chose this specifically because most of the XFS developers are
also responsible for maintaining enterprise distro kernels, and so
we always thinking about how we are going to maintain the upstream
code we release today because it will have a 10-15 year active
support life.  This is also why the deprecation notice in
Documentation/admin-guide/xfs.rst has this caveat:

	Note: Distributors may choose to withdraw V4 format support earlier than
	the dates listed above.

Distros might chose to remove deprecated functionality immediately
rather than rely on, say, LTS kernel support for functionality that
upstream developers are clearly not focussing their efforts on
developing further.

Hence we have to acknowledge that fact that once upstream has
deprecated a feature, it's up to distros to decide how they want to
handle long term support for that feature. The upstream LTS kernel
maintainers are going to have to decide on their own policy, too,
because we cannot bind upstream maintenance decisions on random
individual downstream support constraints. Downstream has to choose
for itself how it handles upstream deprecation notices but, that
said, upstream developers also need to listen to downstream distro
support and deprecation requirements...

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com

Powered by blists - more mailing lists