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. - 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
