From: Jan Kara <jack@suse.cz>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Theodore Ts'o <tytso@mit.edu>, NeilBrown <neilb@suse.de>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
Dave Chinner <david@fromorbit.com>,
Eric Sandeen <sandeen@sandeen.net>,
Steven Rostedt <rostedt@goodmis.org>,
Guenter Roeck <linux@roeck-us.net>,
Christoph Hellwig <hch@infradead.org>,
ksummit@lists.linux.dev, linux-fsdevel@vger.kernel.org
Subject: Re: [MAINTAINERS/KERNEL SUMMIT] Trust and maintenance of file systems
Date: Mon, 18 Sep 2023 13:14:02 +0200 [thread overview]
Message-ID: <20230918111402.7mx3wiecqt5axvs5@quack3> (raw)
In-Reply-To: <CAHk-=wjHarh2VHgM57D1Z+yPFxGwGm7ubfLN7aQCRH5Ke3_=Tg@mail.gmail.com>
On Sun 17-09-23 12:45:30, Linus Torvalds wrote:
> Because yes, buffer heads _are_ old and overly simplistic. And I don't
> really disagree with people who don't want to extend on them any more.
> There are better models.
>
> I think buffer heads are great for one thing, and really one thing
> only: legacy use cases.
>
> So I don't think it should be a shock to anybody that most of the
> listed filesystems are random old legacy cases (or related to such -
> exfat).
>
> But "old" does not mean "bad". And legacy in many ways is worth
> cherishing. It needs to become a whole lot more painful than buffer
> heads have ever been to be a real issue.
I agree. On the other hand each filesystem we carry imposes some
maintenance burden (due to tree wide changes that are happening) and the
question I have for some of them is: Do these filesystems actually bring
any value? I.e., are there still any users left? Sadly that's quite
difficult to answer so people do bother only if the pain is significant
enough like in the case of reiserfs. But I suspect we could get rid of a
few more without a real user complaining (e.g. Shaggy said he'd be happy to
deprecate JFS and he's not aware of any users).
> It is in fact somewhat telling that of that list of odds and ends
> there was *one* filesystem that was mentioned in this thread that is
> actively being deprecated (and happens to use buffer heads).
>
> And that filesystem has been explicitly not maintained, and is being
> deprecated partly exactly because it is the opposite of cherished. So
> the pain isn't worth it.
>
> All largely for some rather obvious non-technical reasons.
>
> So while reiserfs was mentioned as some kind of "good model for
> deprecation", let's be *real* here. The reason nobody wants to have
> anything to do with reiserfs is that Hans Reiser murdered his wife.
Well, I agree that's (consciously or unconsciously) the non-technical part
of the reason. But there's also a technical one. Since Hans' vision how
things should be didn't always match how the rest of the VFS was designed,
reiserfs has accumulated quite some special behavior which is very easy to
break. And because reiserfs testing is non-existent, entrusting your data
to reiserfs is more and more a Russian roulette kind of gamble. So the two
existing reiserfs users that contacted me after announcing reiserfs
deprecation both rather opted for migrating to some other filesystem.
> And I really *really* hope nobody takes that to heart as a good model
> for filesystem deprecation.
LOL :).
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2023-09-18 11:15 UTC|newest]
Thread overview: 97+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-30 14:07 [MAINTAINERS/KERNEL SUMMIT] Trust and maintenance of file systems Christoph Hellwig
2023-09-05 23:06 ` Dave Chinner
2023-09-05 23:23 ` Matthew Wilcox
2023-09-06 2:09 ` Dave Chinner
2023-09-06 15:06 ` Christian Brauner
2023-09-06 15:59 ` Christian Brauner
2023-09-06 19:09 ` Geert Uytterhoeven
2023-09-08 8:34 ` Christoph Hellwig
2023-09-07 0:46 ` Bagas Sanjaya
2023-09-09 12:50 ` James Bottomley
2023-09-09 15:44 ` Matthew Wilcox
2023-09-10 19:51 ` James Bottomley
2023-09-10 20:19 ` Kent Overstreet
2023-09-10 21:15 ` Guenter Roeck
2023-09-11 3:10 ` Theodore Ts'o
2023-09-11 19:03 ` James Bottomley
2023-09-12 0:23 ` Dave Chinner
2023-09-12 16:52 ` H. Peter Anvin
2023-09-09 22:42 ` Kent Overstreet
2023-09-10 8:19 ` Geert Uytterhoeven
2023-09-10 8:37 ` Bernd Schubert
2023-09-10 16:35 ` Kent Overstreet
2023-09-10 17:26 ` Geert Uytterhoeven
2023-09-10 17:35 ` Kent Overstreet
2023-09-11 1:05 ` Dave Chinner
2023-09-11 1:29 ` Kent Overstreet
2023-09-11 2:07 ` Dave Chinner
2023-09-11 13:35 ` David Disseldorp
2023-09-11 17:45 ` Bart Van Assche
2023-09-11 19:11 ` David Disseldorp
2023-09-11 23:05 ` Dave Chinner
2023-09-26 5:24 ` Eric W. Biederman
2023-09-08 8:55 ` Christoph Hellwig
2023-09-08 22:47 ` Dave Chinner
2023-09-06 22:32 ` Guenter Roeck
2023-09-06 22:54 ` Dave Chinner
2023-09-07 0:53 ` Bagas Sanjaya
2023-09-07 3:14 ` Dave Chinner
2023-09-07 1:53 ` Steven Rostedt
2023-09-07 2:22 ` Dave Chinner
2023-09-07 2:51 ` Steven Rostedt
2023-09-07 3:26 ` Matthew Wilcox
2023-09-07 8:04 ` Thorsten Leemhuis
2023-09-07 10:29 ` Christian Brauner
2023-09-07 11:18 ` Thorsten Leemhuis
2023-09-07 12:04 ` Matthew Wilcox
2023-09-07 12:57 ` Guenter Roeck
2023-09-07 13:56 ` Christian Brauner
2023-09-08 8:44 ` Christoph Hellwig
2023-09-07 3:38 ` Dave Chinner
2023-09-07 11:18 ` Steven Rostedt
2023-09-13 16:43 ` Eric Sandeen
2023-09-13 16:58 ` Guenter Roeck
2023-09-13 17:03 ` Linus Torvalds
2023-09-15 22:48 ` Dave Chinner
2023-09-16 19:44 ` Steven Rostedt
2023-09-16 21:50 ` James Bottomley
2023-09-17 1:40 ` NeilBrown
2023-09-17 17:30 ` Linus Torvalds
2023-09-17 18:09 ` Linus Torvalds
2023-09-17 18:57 ` Theodore Ts'o
2023-09-17 19:45 ` Linus Torvalds
2023-09-18 11:14 ` Jan Kara [this message]
2023-09-18 17:26 ` Linus Torvalds
2023-09-18 19:32 ` Jiri Kosina
2023-09-18 19:59 ` Linus Torvalds
2023-09-18 20:50 ` Theodore Ts'o
2023-09-18 22:48 ` Linus Torvalds
2023-09-18 20:33 ` H. Peter Anvin
2023-09-19 4:56 ` Dave Chinner
2023-09-25 9:43 ` Christoph Hellwig
2023-09-27 22:23 ` Dave Kleikamp
2023-09-19 1:15 ` Dave Chinner
2023-09-19 5:17 ` Matthew Wilcox
2023-09-19 16:34 ` Theodore Ts'o
2023-09-19 16:45 ` Matthew Wilcox
2023-09-19 17:15 ` Linus Torvalds
2023-09-19 22:57 ` Dave Chinner
2023-09-18 14:54 ` Bill O'Donnell
2023-09-19 2:44 ` Dave Chinner
2023-09-19 16:57 ` James Bottomley
2023-09-25 9:38 ` Christoph Hellwig
2023-09-25 14:14 ` Dan Carpenter
2023-09-25 16:50 ` Linus Torvalds
2023-09-07 9:48 ` Dan Carpenter
2023-09-07 11:04 ` Segher Boessenkool
2023-09-07 11:22 ` Steven Rostedt
2023-09-07 12:24 ` Segher Boessenkool
2023-09-07 11:23 ` Dan Carpenter
2023-09-07 12:30 ` Segher Boessenkool
2023-09-12 9:50 ` Richard Biener
2023-10-23 5:19 ` Eric Gallager
2023-09-08 8:39 ` Christoph Hellwig
2023-09-08 8:38 ` Christoph Hellwig
2023-09-08 23:21 ` Dave Chinner
2023-09-07 0:48 ` Bagas Sanjaya
2023-09-07 3:07 ` Guenter Roeck
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=20230918111402.7mx3wiecqt5axvs5@quack3 \
--to=jack@suse.cz \
--cc=James.Bottomley@hansenpartnership.com \
--cc=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=ksummit@lists.linux.dev \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=neilb@suse.de \
--cc=rostedt@goodmis.org \
--cc=sandeen@sandeen.net \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
/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).