Re: [RFC 0/13] extents and 48bit ext3

[Andreas Dilger <adilger@clusterfs.com>]

On Jun 09, 2006  11:38 -0700, Linus Torvalds wrote:
> On Fri, 9 Jun 2006, Alex Tomas wrote:
> > would "#if CONFIG_EXT3_EXTENTS" be a good solution then?
> 
> Let's put it this way:
>  - have you had _any_ valid argument at all against "ext4"?
> 
> Think about it. Honestly. Tell me anything that doesn't work?

It's funny that everyone is arguing to fork ext3 into ext4, for a feature
that will primarily allow it to work with large disks (that are already
here, not some wacky pipe dream of featuritis as Jeff thinks).  Yet the
same people that are advocating code duplication on a massive scale in
ext4 are against 5 lines of duplication between the VFS and a filesystem,
or in a couple of drivers here and there.

Having two copies of ext3 means we immediately get 2x the bugs, and
no guarantee that they will ever be fixed in ext3 (all of the ext3
maintainers will be solidly on the ext4 bandwagon if it comes to that).
It also means that two virtually identical copies of the same code
will be in memory at the same time (one for ext3 and another for ext4)
polluting the cache, even though some developers complain that a single
EXPORT_SYMBOL is "bloating" the kernel.  This also means two inode slabs
causing memory fragmentation, etc.

The other issue is that adding a new "ext4" filesystem type will cause
userspace tools to break that assume they know something about the
filesystem type.  They will all detect the filesystem as "ext3" and try
to mount it as such, when the required kernel filesystem is ext4.  Or
we will need to have "mkfs.ext4", "fsck.ext4", etc, for no particular
reason.

Either a system upgrades totally to ext4 to avoid the duplication of code
in memory (and breaks ALL backward compatibility, for no good reason), or
it lives with "only mount filesystems as 'ext4' when they need it" and the
code will rarely be used.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.