linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Byron Stanoszek <gandalf@winds.org>
Cc: Matthew Wilcox <willy@infradead.org>,
	Dave Chinner <david@fromorbit.com>, Jan Kara <jack@suse.cz>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	reiserfs-devel@vger.kernel.org
Subject: Re: Is it time to remove reiserfs?
Date: Fri, 25 Feb 2022 14:23:00 +0100	[thread overview]
Message-ID: <20220225132300.GC18720@1wt.eu> (raw)
In-Reply-To: <257dc4a9-dfa0-327e-f05a-71c0d9742e98@winds.org>

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".

But if instead it's said "will not pass 2023", it's easier to understand
that it must not be shipped anymore even with todays kernels if the
intent is to place them in products for a long time.

Just my two cents,
Willy

  reply	other threads:[~2022-02-25 13:23 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-20 12:13 Is it time to remove reiserfs? Matthew Wilcox
2022-02-20 23:21 ` Edward Shishkin
2022-02-20 23:22   ` [PATCH] reiserfs: get rid of AOP_FLAG_CONT_EXPAND flag Edward Shishkin
2022-02-22 10:27     ` Jan Kara
2022-02-22 13:38       ` Matthew Wilcox
2022-02-23 12:17         ` Jan Kara
2022-02-22 10:04 ` Is it time to remove reiserfs? Jan Kara
2022-02-22 22:16   ` Dave Chinner
2022-02-23 14:48     ` Byron Stanoszek
2022-02-23 15:28       ` Byron Stanoszek
2022-03-17  8:53         ` Thomas Dreibholz
2022-03-17  9:43           ` Jan Kara
2022-02-24  8:46       ` Jan Kara
2022-02-24 14:24         ` Byron Stanoszek
2022-02-24 21:06       ` Matthew Wilcox
2022-02-25 13:10         ` Byron Stanoszek
2022-02-25 13:23           ` Willy Tarreau [this message]
2022-02-25 22:56             ` Dave Chinner
2022-02-26  0:00               ` Theodore Ts'o
2022-04-02 10:57     ` Pavel Machek
2022-04-05 23:04       ` Dave Chinner
2022-04-02 10:54   ` Pavel Machek
2022-04-04  8:55     ` Jan Kara
2022-04-04 10:07       ` Pavel Machek
2022-04-04 10:18         ` Willy Tarreau
2022-04-04 10:58           ` Pavel Machek
2022-04-04 13:05             ` Jan Kara
2022-04-04 12:55           ` Jan Kara
2022-04-04 13:16             ` Willy Tarreau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220225132300.GC18720@1wt.eu \
    --to=w@1wt.eu \
    --cc=david@fromorbit.com \
    --cc=gandalf@winds.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=reiserfs-devel@vger.kernel.org \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).