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

[Jeff Garzik]

Andrew Morton wrote:
> On Fri, 09 Jun 2006 14:40:56 -0400
> Jeff Garzik <jeff@xxxxxxxxxx> wrote:
>
> > Andreas Dilger wrote:
> > > Having a single codebase for everyone means that it is continually maintained
> > > and users of ext3 aren't left out in the cold.
> > That implies continually upgrading ext3 for newer storage technologies, 
> > which in turn implies adding all sorts of incompatible formats to 
> > support better storage scaling, and new usage models.
>
> Look, I'm not certain either way on this - I really don't like the format
> incompatibility and I'd like to see a breakdown of the performance benefits
> of each of the proposed new features so perhaps we can cherrypick.  And I'm
> deferring judgement until I've looked at some patches.
>
> But Jeff, please stop this wild exaggeration!  "continually upgrading",
> "all sorts of incompatible formats".  It's not helping anything.  
>
> Today's ext3 is, afaik, 100% on-disk compatible with ext3 from five years
> ago, and probably with RH's 2.2-based implementation.  So we have not done
> and will not do the things which you are FUDding us about.
>
> This is (again, as far as I recall) the first on-disk-incompatible change
> in ext3 which has ever been proposed.  It's not a thing which is done
> lightly and it's not a thing which is likely to happen again for a very long
> time indeed.

That's not really true, I include in the list EXT3_FEATURE_RO_COMPAT_*, 
EXT3_FEATURE_INCOMPAT_*, 32-bit uid/gid, ISTR some ACL-related mess, and 
the online resizing stuff that produces a filesystem slightly different 
than what mke2fs would produce for the same [larger] sized block device. 
 Red Hat has had at least one problem in the past where users were 
annoyed at format changes (htree?).

I certainly grant that extents and 48bit are format changes on a -much- 
larger scale than in the past.  Absolutely.

That's why I feel that this is a good point to calm down ext3 
development, and start putting stuff like extents into ext4.  If we are 
starting to make major changes to the format, that should be a signal 
that we are starting to work on a new filesystem, rather than patching 
an old one.

I disagree with the "years to stabilize ext4" argument, because we are 
starting from a known good point.  I think ext4 will be easier to 
maintain and tune for modern storage systems, if we don't have to worry 
as much about that stuff for ext3.

	Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/