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 [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]
