All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Jan Kara <jack@suse.cz>
Cc: Matthew Wilcox <willy@infradead.org>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	reiserfs-devel@vger.kernel.org
Subject: Re: Is it time to remove reiserfs?
Date: Sat, 2 Apr 2022 12:54:55 +0200	[thread overview]
Message-ID: <20220402105454.GA16346@amd> (raw)
In-Reply-To: <20220222100408.cyrdjsv5eun5pzij@quack3.lan>

[-- Attachment #1: Type: text/plain, Size: 2218 bytes --]

Hi!

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

I believe I've seen reiserfs in recent Arch Linux ARM installation on
PinePhone. I don't really think you can remove a feature people are
using.

Best regards,
								Pavel
-- 
People of Russia, stop Putin before his war on Ukraine escalates.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

  parent reply	other threads:[~2022-04-02 10:54 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
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 [this message]
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=20220402105454.GA16346@amd \
    --to=pavel@ucw.cz \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.