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

Jeff Garzik
2006-06-09T17:58:49Z

Theodore Tso wrote:
> And in any case, this is why we have to think very carefully before
> forking the codebase between ext3 and "ext4". The work that we might
> use to slim down ext4_inode_info would also have to be backported to
> ext3_inode_info before ext3 users see the benefit. And there may also

No, the entire point is that you stop backporting all the junk, and just
leave ext3 as is. Let it sit, let it stabilize.

New development -- including inode slimming work -- can be best done in
ext4. With ext3, you are fighting all those old back-compat features
and associated code paths bloating up the in-core inode [code].

_Obviously_ there may be bugs found in three codebases, rather than two.
But over time those will trickle off, particularly when developers
successfully resist the urge to continue modifying ext[23].

There will always newer, bigger storage situations and arrays, and I
think it's a mistake to continue modifying the same Linux filesystem to
support all these situations. The logical end result is a big, unwieldy
codebase that supports $N metadata, data, and journal formats.

In the same way we don't stuff support for all PCI ethernet or SATA
drivers into the same .o file, we shouldn't keep stuffing support for
all these varying filesystem formats into ext3.o. That creates (and
extents exacerbate) the "what ext3 fs am I mounting, today?" support
problem.

Jeff