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

Linus Torvalds
2006-06-10T20:02:40Z

On Sat, 10 Jun 2006, Linus Torvalds wrote:
>
> ext2 is half the size of ext3, and that's ignoring JBD entirely.

Btw, let me say again that I'm fairly neutral on any particular individual
feature (ie the 48-bit thing doesn't actually move me all that much in
itself), but that from a maintenance standpoint, I think splitting off
filesystems and drivers has been a _huge_ success.

Starting from scratch - even if you literally start from the same
code-base - and allowing the old functionality to remain undisturbed is
just a very nice model. Yeah, yeah, it has some diskspace cost (although
at least from a git perspective, even that isn't really true), but we've
seen both in drivers and in filesystems how splitting things up has been a
great thing to do.

Sometimes it's a great thing just because five years later, it turns out
that nobody even uses the legacy thing, and you decide to at that point
just remove the driver (or filesystem, but so far it's never been the
case for filesystems even if smbfs is a potential victim of this in the
not _too_ distant future), because the new version simply does everything
better.

And that's _not_ a failure of the model. It's a success too. But so is the
above commentary on ext2, when the "old driver/filesystem is still used
and maintained by odd people". It's just two different possible outcomes
of the decision to do development separately from an older user base.

And again, I'd like to stress the _user_base_ over the _code_base_. In
many ways, that's the much more important split. I suspect Jeff has seen
this in drivers, where a lot of users simply do not want to have a new
driver, because it does some huge fundamental improvement for new users
but doesn't work for old ethernet cards, for example, because it missed
some old use case depended on a legacy feature that just doesn't fit well
into the new (and obviously improved) world-view.

So we've often seen a driver that _could_ have handled different versions
of the same card/chip split into an "old" and a "new" driver, and on the
whole it has always been positive - even if eventually the old driver just
becomes irrelevant for one reason or another.

Duplication isn't actually bad. It's what often allows experimentation,
and streamlining. In drivers, for example, duplication is _often_ done as
part of simply dropping support for old cards in the new version, but also
by dropping and simplifying the old driver that now has a much clearer
"raison d'etre", aka "user base".

Which gets me back to the whole "'user base' matters more than 'code
base'" argument, because it's literally the user base that determines
development (or lack of it - non-development is often the big reason for a
user base, as anybody who works for a distribution maintainer should know
intimately).

Linus