lkml.org 
[lkml]   [2006]   [Jun]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Ext2-devel] [RFC 0/13] extents and 48bit ext3


    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
    separable.

    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
    costs.

    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.

    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/

    \
     
     \ /
      Last update: 2009-11-18 23:46    [W:0.023 / U:31.388 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site