Message-ID: <20150901025335.GF7642@thunk.org>
Date:	Mon, 31 Aug 2015 22:53:35 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Raymond Jennings <shentino@...il.com>, Jan Kara <jack@...e.cz>,
	LKML <linux-kernel@...r.kernel.org>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [GIT PULL] Ext3 removal, quota & udf fixes

On Mon, Aug 31, 2015 at 03:39:38PM -0700, Linus Torvalds wrote:
> 
> That's not my only worry. Things like "can you go back to ext3-only"
> is an issue too - I don't think that's been a big priority for ext4
> any more, and if there are any existing hold-outs that still use ext3,
> they may want to be able to go back to old kernels.

Yes, you can go back to ext3-only.  In fact, we do *not* automatically
upgrade the file system to use ext4-specific features.

> So it's not just a "you can use ext4 instead" issue. Can you do that
> *without* then forcing an upgrade forever on that partition? I'm not
> sure the ext4 people are really even willing to guarantee that kind of
> backwards compatibility.

Actually, we do guarantee this.  It's considered poor form to
automatically change the superblock to add new file system features in
a way that would break the ability for the user to roll back to an
older kernel.  This isn't just for ext3->ext4, but for new ext4
features such as metadata checksumming.  The user has to explicitly
enable the feature using "tune2fs -O new_feature /dev/sdXX".

A file system with ext3-only features is part of regression test
suites.  I also test an ext3 file system that has been converted to
ext4 using the tune2fs command, data=journal, nojournal, new
experimental features such as inline data, etc., etc.:

BEGIN TEST 4k: Ext4 4k block Mon Aug 24 23:01:09 EDT 2015
BEGIN TEST 1k: Ext4 1k block Mon Aug 24 23:47:13 EDT 2015
BEGIN TEST ext3: Ext4 4k block emulating ext3 Tue Aug 25 00:40:19 EDT 2015
BEGIN TEST nojournal: Ext4 4k block w/ no journal Tue Aug 25 01:23:16 EDT 2015
BEGIN TEST ext3conv: Ext4 4k block w/nodelalloc and no flex_bg Tue Aug 25 02:04:52 EDT 2015
BEGIN TEST dioread_nolock: Ext4 4k block w/dioread_nolock Tue Aug 25 02:48:32 EDT 2015
BEGIN TEST data_journal: Ext4 4k block w/data=journal Tue Aug 25 03:34:30 EDT 2015
BEGIN TEST inline: Ext4 4k block w/inline Tue Aug 25 04:36:47 EDT 2015
BEGIN TEST bigalloc: Ext4 4k block w/bigalloc Tue Aug 25 05:22:08 EDT 2015
BEGIN TEST bigalloc_1k: Ext4 1k block w/bigalloc Tue Aug 25 06:20:54 EDT 2015

I fire off the test suite using a single command: "gce-xfstests full"
which launches the regression test into the cloud (approximate cost
using Google Compute Engine: $1.50, at retail rates), and then 7-8
hours later, the results get e-mailed to me.  These tests get run
regularly during the development cycle, and I always do at least one
full test run before I send you each pull request.

So supporting and continuing to do regression testing for ext3 is
something we're doing today and I am willing to commit to continue to
do.

> I could be ok with removing ext3 in theory, but I haven't seen a lot
> of rationale for it, and I don't know if there are still users who may
> have their own good reasons to stay with ext3. Maybe there has been
> lots of discussion about this on fsdevel (which I don't follow), and
> I'm just lacking the background, but if so I want to see that
> background. Not just a oneliner description that basically says
> "remove ext3 support".

The main rationale is that two code bases is harder to support than
one.  When bugs get fixed in ext4, they don't necessarily get
back-propagated to ext3 except for a manual process where Jan notices
that a bug fixed in ext4 is also in ext3, and he manually ports the
patch over.

Both Red Hat and SuSE, as well as Debian and Ubuntu, are using ext4
with CONFIG_EXT4_USE_FOR_EXT23 for a couple of years now to support
ext2 and ext3 file systems.  So with the exception of some really
ancient enterprise Linux distros, and people who are manually
configuring their systems, very few people are likely using ext3 code
base, which means the chances that it bitrots increases.  Basically,
it's only been Jan's tireless work that has kept that from happening,
given that all of the major distro's have been using ext4 to support
ext2 and ext3 file systems.

Given that all of the major distributions are using ext4 to support
ext3, full backwards compatibility support for ext3 is something we
support today and will have to continue supporting regardless of
whether or not ext3 gets removed from the kernel sources.

Cheers,

						- Ted

P.S.  Even though most distributions are also using ext4 to support
ext2, I don't support removing ext2 at this time.  Like minix, it's a
simple file system that can be easily used by others to understand
what's needed to create a new file system.  
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists