archive mirror
 help / color / mirror / Atom feed
From: Byron Stanoszek <>
To: Dave Chinner <>
Cc: Jan Kara <>, Matthew Wilcox <>,,,
Subject: Re: Is it time to remove reiserfs?
Date: Wed, 23 Feb 2022 10:28:39 -0500 (EST)	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, 23 Feb 2022, Byron Stanoszek wrote:
> On Wed, 23 Feb 2022, Dave Chinner wrote:
>>  On Tue, Feb 22, 2022 at 11:04:08AM +0100, Jan Kara wrote:
>>>  Hello!
>>>  On Sun 20-02-22 12:13:04, Matthew Wilcox wrote:
>>>>  Keeping reiserfs in the tree has certain costs.  For example, I would
>>>>  very much like to remove the 'flags' argument to ->write_begin.  We have
>>>>  the infrastructure in place to handle AOP_FLAG_NOFS differently, but
>>>>  AOP_FLAG_CONT_EXPAND is still around, used only by reiserfs.
>>>>  Looking over the patches to reiserfs over the past couple of years,
>>>>  there
>>>>  are fixes for a few syzbot reports and treewide changes.  There don't
>>>>  seem to be any fixes for user-spotted bugs since 2019.  Does reiserfs
>>>>  still have a large install base that is just very happy with an old
>>>>  stable filesystem?  Or have all its users migrated to new and exciting
>>>>  filesystems with active feature development?
>>>>  We've removed support for senescent filesystems before (ext, xiafs), so
>>>>  it's not unprecedented.  But while I have a clear idea of the benefits
>>>>  to
>>>>  other developers of removing reiserfs, I don't have enough information
>>>>  to
>>>>  weigh the costs to users.  Maybe they're happy with having 5.15 support
>>>>  for their reiserfs filesystems and can migrate to another filesystem
>>>>  before they upgrade their kernel after 5.15.
>>>>  Another possibility beyond outright removal would be to trim the kernel
>>>>  code down to read-only support for reiserfs.  Most of the quirks of
>>>>  reiserfs have to do with write support, so this could be a useful way
>>>>  forward.  Again, I don't have a clear picture of how people actually
>>>>  use reiserfs, so I don't know whether it is useful or not.
>>>>  NB: Please don't discuss the personalities involved.  This is purely a
>>>>  "we have old code using old APIs" discussion.
>>>  So from my distro experience installed userbase of reiserfs is pretty
>>>  small
>>>  and shrinking. We still do build reiserfs in openSUSE / SLES kernels but
>>>  for enterprise offerings it is unsupported (for like 3-4 years) and the
>>>  module
>>>  is not in the default kernel rpm anymore.
>>>  So clearly the filesystem is on the deprecation path, the question is
>>>  whether it is far enough to remove it from the kernel completely. Maybe
>>>  time to start deprecation by printing warnings when reiserfs gets mounted
>>>  and then if nobody yells for year or two, we'll go ahead and remove it?
>>  Yup, I'd say we should deprecate it and add it to the removal
>>  schedule. The less poorly tested legacy filesystem code we have to
>>  maintain the better.
>>  Along those lines, I think we really need to be more aggressive
>>  about deprecating and removing filesystems that cannot (or will not)
>>  be made y2038k compliant in the new future. We're getting to close
>>  to the point where long term distro and/or product development life
>>  cycles will overlap with y2038k, so we should be thinking of
>>  deprecating and removing such filesystems before they end up in
>>  products that will still be in use in 15 years time.
>>  And just so everyone in the discussion is aware: XFS already has a
>>  deprecation and removal schedule for the non-y2038k-compliant v4
>>  filesystem format. It's officially deprecated right now, we'll stop
>>  building kernels with v4 support enabled by default in 2025, and
>>  we're removing the code that supports the v4 format entirely in
>>  2030.
> 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.
> I originally installed Reiserfs on these systems as early as 2005 due to the
> tail-packing feature, which saved space with many small files on older
> harddrives. Since then, I witnessed the development of ext4, and then btrfs.
> For a long time, these newer filesystems had occasional reports of
> instabilities and lost data, and so I shied away from using them. Meanwhile,
> Reiserfs reached a level of maturity and no longer had active development on
> it, except for the occasional bugfix. I felt this was a filesystem I could
> trust going forward (despite its relative slowness), even after popular Linux
> distributions eventually dropped it from being installed by default.
> I have only recently begun to use XFS on newer installs, only since the XFS
> developers added bigtime support for y2038k. But for existing installs, I ask
> that we keep Reiserfs supported in the kernel a little longer. Perhaps use
> the same deprecation schedule that was picked for XFS v4 (roughly 10 years of
> deprecation before eventual removal)?

Sorry, I meant to say 5 years here, not 10.


  reply	other threads:[~2022-02-23 15:28 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 [this message]
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
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:

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

  git send-email \ \ \ \ \ \ \ \ \

* 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).