+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
