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

[Jeff Garzik <jeff@garzik.org>]

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