linux-kernel - Re: Is it time to remove reiserfs?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220225132300.GC18720@1wt.eu>
Date:   Fri, 25 Feb 2022 14:23:00 +0100
From:   Willy Tarreau <w@....eu>
To:     Byron Stanoszek <gandalf@...ds.org>
Cc:     Matthew Wilcox <willy@...radead.org>,
        Dave Chinner <david@...morbit.com>, 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 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