From: Jan Kara <jack@suse.cz>
To: Dave Chinner <david@fromorbit.com>
Cc: Jan Kara <jack@suse.cz>,
reiserfs-devel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
Matthew Wilcox <willy@infradead.org>,
Edward Shishkin <edward.shishkin@gmail.com>
Subject: Re: [PATCH] reiserfs: Deprecate reiserfs
Date: Fri, 25 Feb 2022 13:52:09 +0100 [thread overview]
Message-ID: <20220225125209.6dv6osndesrc346z@quack3.lan> (raw)
In-Reply-To: <20220223213127.GI3061737@dread.disaster.area>
On Thu 24-02-22 08:31:27, Dave Chinner wrote:
> On Wed, Feb 23, 2022 at 03:26:53PM +0100, Jan Kara wrote:
> > Reiserfs is relatively old filesystem and its development has ceased
> > quite some years ago. Linux distributions moved away from it towards
> > other filesystems such as btrfs, xfs, or ext4. To reduce maintenance
> > burden on cross filesystem changes (such as new mount API, iomap, folios
> > ...) let's add a deprecation notice when the filesystem is mounted and
> > schedule its removal to 2024.
>
> Two years might be considered "short notice" for a filesystem, but I
> guess that people running it because it is stable will most likely
> also linger on stable kernels where it will live "maintained" for
> many years after it has been removed from the upstream code base.
Yeah, I guess that is the case usually. Anyway based on feedback from one
reiserfs user I've pushed the date to 2025.
> > Signed-off-by: Jan Kara <jack@suse.cz>
> > ---
> > fs/reiserfs/Kconfig | 10 +++++++---
> > fs/reiserfs/super.c | 2 ++
> > 2 files changed, 9 insertions(+), 3 deletions(-)
> >
> > Here's my suggestion for deprecating reiserfs. If nobody has reasons against
> > this, I'll send the patch to Linus during the next merge window.
>
> Is there a deprecation/removal schedule somewhere that documents
> stuff like this? We documented in the XFS section of the kernel
> admin guide (where we also document mount option and
> sysctl deprecation and removal schedules), but I don't think
> anything like that exists for reiserfs or for filesystems in
> general.
The only document I'm aware of is Documentation/process/deprecated.rst
for which filesystem deprecation seems inappropriate. So no I don't think
we have such general document for filesystems.
> Other than that, the patch looks good.
Thanks for review!
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
prev parent reply other threads:[~2022-02-25 12:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-23 14:26 [PATCH] reiserfs: Deprecate reiserfs Jan Kara
2022-02-23 21:31 ` Dave Chinner
2022-02-25 12:52 ` Jan Kara [this message]
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=20220225125209.6dv6osndesrc346z@quack3.lan \
--to=jack@suse.cz \
--cc=david@fromorbit.com \
--cc=edward.shishkin@gmail.com \
--cc=linux-fsdevel@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