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

[Linus Torvalds <torvalds@osdl.org>]

On Fri, 9 Jun 2006, Alex Tomas wrote:
> 
> I believe it's as stable as before until you mount with extents
> mount option.

That's always a possibility in theory, and almost never in practice.

Btw, I don't care about extents _per_se_. I do care about the fact that 
people seem to think that code gets better as it supports more features. 
Not so.

The whole logic of "code sharing is good" is a huge mistake. Shared code 
is not at all better than individual code snippets, and often much much 
worse. In particular, if the shared code has separate code-paths, not just 
twice as complicated: it's _more_ than twice as bad, since it introduces 
the conditionals _and_ it introduces the very real risk of the conditional 
being taken the wrong way by mistake.

In contrast, the last time two different filesystems introduced bugs in 
each other was approximately "never". They simply don't modify each others 
code, they don't look at each others data structures, and they don't jump 
into each others routines.

So two separate filesystems are _less_ to maintain than one big one. Even 
if there's a lot of code that -could- be shared.

And no, extents in themselves aren't necessarily "the thing" that drives 
it from maintainable to unmaintainable. This crap grows over time. But I 
would _serious_ suggest that starting anew with a "new" filesystem, and 
taking the time to actually also get _rid_ of some of the baggage would 
quite likely be a good idea.

Just as an example: ext3 _sucks_ in many ways. It has huge inodes that 
take up way too much space in memory. It has absolutely disgusting code to 
handle directory reading and writing (buffer heads! In 2006!). It's 
conditional indexing code is horrible. Its performance absolutely sucks 
when the journal is being drained or something.

Are you going to improve on any of those _fundamnetal_ problems? Or are 
you going to make them worse?

Hint: I'm betting you're not going to improve them by adding more 
features.

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/