[LSF/MM TOPIC] Drop ext2/ext3 codebase? When?

[Jan Kara <jack@suse.cz>]

  Hi,

  I'm not completely sure this is interesting for enough people but maybe
it is...

As you well know, there are three independent code bases in kernel
implementing ext-based filesystems - ext2, ext3, and ext4. Of course it
costs some effort to maintain them all in a reasonably good condition so
once in a while someone comes and proposes we should drop one of ext2, ext3
or both. So I'd like to gather input what people think about this - should
we ever drop ext2 / ext3 codebases? If yes, under what condition do we deem
it is OK to drop it?

To give some facts:
Feature-wise, ext4 should now be almost a superset of both ext2 and
ext3. ext4 has nojournal mode to simulate ext2, looking at the code I only
don't see XIP support in ext4, arguably also nobh-mode but I personally
feel that these days the complication in the code isn't worth it. As far as
I know it should be backward compatible to writeably mount ext2/ext3
filesystem with ext4 (i.e., no incompatible features should be turned on
magically).

On the other hand there are differences noticeable under some conditions -
e.g. delayed allocation, data=ordered mode of ext3 gives better data
integrity than that of ext4 in practice (it's just a side effect we never
promised but app developers somehow got used to it ;), different allocation
decisions, and I believe there are more of these subtle differences.

Then of course there is the factor of the codebase itself: Ext2 - ~9k
lines, Ext3+JBD - 24k lines, Ext4+JBD2 - 43k lines. Ext2 codebase is so
simple that it sometimes serves as a "model filesystem". But arguably it
also bitrots slowly so copy-and-pasting from ext2 need not be clever idea
anymore.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR