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

Jeff Garzik
2006-06-09T19:16:17Z

Andrew Morton wrote:
> On Fri, 09 Jun 2006 14:40:56 -0400
> Jeff Garzik <jeff@garzik.org> 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