From: "Theodore Ts'o" <tytso@mit.edu>
To: Dave Chinner <david@fromorbit.com>
Cc: Matthew Wilcox <willy@infradead.org>,
jfs-discussion@lists.sourceforge.net,
linux-fsdevel@vger.kernel.org,
Christoph Hellwig <hch@infradead.org>,
"linux-ext4@vger.kernel.org Darrick J . Wong" <djwong@kernel.org>
Subject: Re: [RFC PATCH 0/9] Convert JFS to use iomap
Date: Sat, 28 May 2022 14:59:31 -0400 [thread overview]
Message-ID: <YpJxEwl+t93pSKLk@mit.edu> (raw)
In-Reply-To: <20220528053639.GI3923443@dread.disaster.area>
+linux-ext4
On Sat, May 28, 2022 at 03:36:39PM +1000, Dave Chinner wrote:
> The other filesystem that uses nobh is the standalone ext2
> filesystem that nobody uses anymore as the ext4 module provides ext2
> functionality for distros these days. Hence there's an argument that
> can be made for removing fs/ext2 as well. In which case, the whole
> nobh problem goes away by deprecating and removing both the
> filesysetms that use that infrastructure in 2 years time....
This got brought up at this past week's ext4 video chat, where Willy
asked Jan (who has been maintaining ext2) whether he would be open to
converting ext2 to use iomap. The answer was yes. So once jfs and
ext2 are converted, we'll be able to nuke the nobh code.
From Willy's comments on the video chat, my understanding is that jfs
was even simpler to convert that ext2, and this allows us to remove
the nobh infrastructure without asking the question about whether it's
time to remove jfs.
> > We also need to convert more filesystems to use iomap.
>
> We also need to deprecate and remove more largely unmaintained and
> unused filesystems. :)
Well, Dave Kleikamp is still around and sends jfs pull requests from
time to time, and so it's not as unmaintained as, say, fs/adfs,
fs/freevxs, fs/hpfs, fs/minix, and fs/sysv.
As regards to minixfs, I'd argue that ext2 is a better reference file
system than minixfs. So..... are we ready to remove minixfs? I could
easily see that some folks might still have sentimental attachment to
minixfs. :-)
> Until ext4 is converted to use iomap, we realistically cannot ask
> anyone to use iomap....
That's something that we've been discussing on the ext4 video chats.
What we can probably do is to convert buffered I/O to use iomap in
stages, first starting with the easy case, and then progressing to the
more complex ones:
* page_size == block_size, !fscrypt, !fsverity, !data=journal
* page_size != block_size, !fscrypt, !fsverity, !data=journal
* fsverity
* fscrypt
At that point, the hard, remaining case is what to do with
data=journal. data=journal is already barely maintained; we don't
support direct i/o, delayed allocation, etc., There have been some
specialized users for it, but it's probably more for interesting
research applications than anything else.
So the question is whether we keep it as a special case, and never
convert it over to iomap, or decide that it's time to deprecate and
rip out data=journal support. We don't need to make that decision
right away, and so long as it remains a special case where it doesn't
burden the rest of the kernel, we might end up keeping it so long as
it remains a minimal maintenance burden for ext4. I duuno....
In any case, rest assured that there have been quite a lot of
discussions about how to convert all (or 99.99%) of ext4 to use iomap.
Cheers,
- Ted
next prev parent reply other threads:[~2022-05-28 19:08 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-26 19:29 [RFC PATCH 0/9] Convert JFS to use iomap Matthew Wilcox (Oracle)
2022-05-26 19:29 ` [RFC PATCH 1/9] IOMAP_DIO_NOSYNC Matthew Wilcox (Oracle)
2022-05-27 5:35 ` Christoph Hellwig
2022-05-27 13:20 ` Matthew Wilcox
2022-05-26 19:29 ` [RFC PATCH 2/9] jfs: Add jfs_iomap_begin() Matthew Wilcox (Oracle)
2022-05-27 5:41 ` Christoph Hellwig
2022-05-27 13:45 ` Matthew Wilcox
2022-05-27 14:58 ` [Jfs-discussion] " Dave Kleikamp
2022-05-26 19:29 ` [RFC PATCH 3/9] jfs: Convert direct_IO read support to use iomap Matthew Wilcox (Oracle)
2022-05-26 19:29 ` [RFC PATCH 4/9] jfs: Convert direct_IO write " Matthew Wilcox (Oracle)
2022-05-26 19:29 ` [RFC PATCH 5/9] jfs: Remove old direct_IO support Matthew Wilcox (Oracle)
2022-05-26 19:29 ` [RFC PATCH 6/9] jfs: Handle bmap with iomap Matthew Wilcox (Oracle)
2022-05-26 19:29 ` [RFC PATCH 7/9] jfs: Read quota through the page cache Matthew Wilcox (Oracle)
2022-05-27 5:43 ` Christoph Hellwig
2022-05-27 13:56 ` Matthew Wilcox
2022-06-03 14:40 ` generic_quota_read Matthew Wilcox
2022-06-06 7:37 ` generic_quota_read Jan Kara
2022-05-26 19:29 ` [RFC PATCH 8/9] jfs: Write quota through the page cache Matthew Wilcox (Oracle)
2022-05-27 5:46 ` Christoph Hellwig
2022-05-26 19:29 ` [RFC PATCH 9/9] jfs: Convert buffered IO paths to iomap Matthew Wilcox (Oracle)
2022-05-28 0:02 ` [RFC PATCH 0/9] Convert JFS to use iomap Dave Chinner
2022-05-28 2:15 ` Matthew Wilcox
2022-05-28 5:36 ` Dave Chinner
2022-05-28 18:59 ` Theodore Ts'o [this message]
2022-05-29 23:51 ` Dave Chinner
2022-05-31 13:51 ` [Jfs-discussion] " Dave Kleikamp
2022-05-31 15:31 ` Matthew Wilcox
2022-05-31 15:56 ` Dave Kleikamp
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=YpJxEwl+t93pSKLk@mit.edu \
--to=tytso@mit.edu \
--cc=david@fromorbit.com \
--cc=djwong@kernel.org \
--cc=hch@infradead.org \
--cc=jfs-discussion@lists.sourceforge.net \
--cc=linux-fsdevel@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;
as well as URLs for NNTP newsgroup(s).