|| ||Linus Torvalds <torvalds-AT-osdl.org>|
|| ||Alex Tomas <alex-AT-clusterfs.com>|
|| ||Re: [Ext2-devel] [RFC 0/13] extents and 48bit ext3|
|| ||Fri, 9 Jun 2006 10:30:06 -0700 (PDT)|
|| ||Jeff Garzik <jeff-AT-garzik.org>, Andrew Morton <akpm-AT-osdl.org>,
Andreas Dilger <adilger-AT-clusterfs.com>|
On Fri, 9 Jun 2006, Alex Tomas wrote:
> oops :) I don't follow that well ...
> size of in-core inodes is a different problem.
Not really. It's really the same problem: adding features has a real cost.
And the cost is higher if you don't add them in a way that is statically
So I'm not trying to make the in-core inode size be "the thing" to
concentrate on. And I'm not saying that extents is inherently "the thing"
that makes it sane to split up development. That time might have been a
few years ago, or it might be in the future.
So don't get me wrong. I'm (a) generally supporting Jeff in that I think
it makes sense to split projects off occasionally, and maybe even plan on
hopefully make the original project be deleted in the long run (it does
actually happen, although it is fairly rare). And (b) trying to show the
For me, the biggest cost tends to actually be support. A stable filesystem
that is used by thousands and thousands of people and that isn't actually
developed outside of just maintaining it IS A REALLY GOOD THING TO HAVE.
And I'm not saying that just because it's a filesystem, and people get
upset if they lose data. No, I'm saying it because from a maintenance
standpoint, such a filesystem has almost zero cost.
So from a maintenance stanpoint, it's actually a _lot_ more useful to me
(and probably to a lot of other people) if development is done as its own
project, and is merged as its own sub-project. When problems happen, it's
fairly obvious what they are, and it's very much a case of all the people
involved having made that choice ("Hey, you knew it wasn't as stable, but
you wanted it for your special needs").
As an additional bonus, it tends to help find patterns in bug-reports
("ahh, everyone involved is running ext4"). So not only does it not affect
people who don't want to be affected, it also helps _pinpoint_ where
problems are when they do happen.
Also, if it turns out that the stabilization thing worked well, and after
a few years the _new_ code hasn't gotten any changes, and there are no
other real downsides either, they can actually be merged later on too.
That's what we're seeing in the 64-bit architecture support on both s390
and powerpc (and maybe even x86, eventually? Possibly not, but who
knows..). But that's a separate issue.
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
to post comments)