linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Willy Tarreau <w@1wt.eu>
Cc: Pavel Machek <pavel@ucw.cz>, Jan Kara <jack@suse.cz>,
	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: Mon, 4 Apr 2022 14:55:41 +0200	[thread overview]
Message-ID: <20220404125541.tvcf3dwyfvxsnurz@quack3.lan> (raw)
In-Reply-To: <20220404101802.GB8279@1wt.eu>

On Mon 04-04-22 12:18:02, Willy Tarreau wrote:
> Hi Pavel,
> 
> On Mon, Apr 04, 2022 at 12:07:32PM +0200, Pavel Machek wrote:
> > > Well, if someone uses Reiserfs they better either migrate to some other
> > > filesystem or start maintaining it. It is as simple as that because
> > > currently there's nobody willing to invest resources in it for quite a few
> > > years and so it is just a question of time before it starts eating people's
> > > data (probably it already does in some cornercases, as an example there are
> > > quite some syzbot reports for it)...
> > 
> > Yes people should migrate away from Reiserfs. I guess someone should
> > break the news to Arch Linux ARM people.
> > 
> > But I believe userbase is bigger than you think and it will not be
> > possible to remove reiserfs anytime soon.
> 
> I was about to say the opposite until I noticed that one of my main
> dev machine has its kernel git dir on it because it's an old FS from
> a previous instance of this machine before an upgrade and it turns out
> that this FS still had lots of available space to store git trees :-/

:)

> So maybe you're right and there are still a bit more than expected out
> there. However I really think that most users who still have one are in
> the same situation as I am, they're not aware of it. So aside big fat
> warnings at mount time (possibly with an extra delay), there's nothing
> that will make that situation change.
> 
> At the very least disabling it by default in Kconfig and in distros
> should be effective. I really don't think that there are still users
> who regularly update their system and who have it on their rootfs, but
> still having data on it, yes, possibly. The earlier they're warned,
> the better.

Yes, we start with a warning now. Say a year before we really do remove it,
my plan is to refuse to mount it unless you pass a "I really know what I'm
doing" mount option so that we make sure people who possibly missed a
warning until that moment are aware of the deprecation and still have an
easy path and some time to migrate.

Regarding distros, I know that SUSE (and likely RH) do not offer reiserfs
in their installers for quite some time, it is unsupported for the
enterprise offerings (so most if not all paying customers have migrated
away from it). The notice was in LWN, Slashdot, and perhaps other news
sites so perhaps other distro maintainers do notice sooner rather than
later. I can specifically try to reach to Arch Linux given Pavel's notice
to give them some early warning.

								Honza

-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

  parent reply	other threads:[~2022-04-04 12:55 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
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 [this message]
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=20220404125541.tvcf3dwyfvxsnurz@quack3.lan \
    --to=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=reiserfs-devel@vger.kernel.org \
    --cc=w@1wt.eu \
    --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).