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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
