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@xxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
