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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
