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

Jeff Garzik
2006-06-09T20:00:53Z

Gerrit Huizenga wrote:
> On Fri, 09 Jun 2006 14:55:56 EDT, Jeff Garzik wrote:
>> Because it's called backwards compat, when it isn't?
>> Because it is very difficult to find out which set of kernels you are
>> locked out of?
>> Because the filesystem upgrade is stealthy, occurring as it does on the
>> first data write?
>
> Actually, the *only* point being contended here is running older
> kernels on some newer filesystems (created originally with a newer
> kernel), right?
>
> Or do you have examples of where current kernels could not deal
> with an ext3 feature at some point in time?
>
> I would argue that 0.001% of all Linux *users* actually worry about
> this - most of them are right here on the development mailing list.
> So, that group is more vocal, for sure. But, if it works for 99.99+%
> users, aren't we still on the good path, from the point of view of
> those people who actually *use* Linux the most?

The overall objection is to treating ext3 as a highly mutable,
one-size-fits-all filesystem.

Maybe there is value in moving some reiser4 concepts -- a set of
metadata+algorithm plugins -- to the VFS level. I dunno.

But for ext3 specifically, it seems like bolting on extents, 48bit,
delayed allocation, and other new features weren't really suited for the
original ext2-style design. Outside of the support (and marketing,
because that's all version numbers are in the end) issues already
mentioned, I think it falls into the nebulous realm of "taste."

Rather than taking another decade to slowly fix ext2 design decisions,
why not move the process along a bit more rapidly? Release early,
release often...

Jeff