lkml.org 
[lkml]   [2009]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: 2.6.29 -mm merge plans
    Date
    On Wednesday 07 January 2009 10:28:29 Andrew Morton wrote:
    > Christoph Hellwig <hch@infradead.org> wrote:

    > > BTW, the current influx of higher-complexity filesystems certainly
    > > worries me a little.
    >
    > Well yes. Each new filesystem (complex or not) is an additional
    > boatanchor on development of core kernel: block, vfs, MM, etc. So each
    > filesystem should be justified on the basis that it adds sufficient
    > benefit to justify that cost. (And I got mau-muaed for pointing this
    > out in the omfs context, I might add).

    I've found that if the filesystems have active maintainers who are willing
    to help eg. if some MM APIs need to change, then it isn't such a big problem.

    It simply doesn't scale and will not work if an MM developer is expected to
    go through and try to understand *every* filesystem, attempt to change them,
    and test them even though it's non-trivial to even set up and mount a lot
    of these things to test them.

    Each individual filesystem development community already knows their fs code,
    has test environments set up (or presumably can at least mount the thing),
    and only need to understand one little changed aspect of the MM, with the
    help from the MM developer.

    Latter system is efficient and scales, former does not.

    If a filesystem is merged it has to have a pretty good promise that it will
    be well maintained. (obviously it still has to justify a cost, but that cost
    becomes sane)


    > Will nilfs bring enough value to justify it's cost? Hard call. What
    > do you think?
    >
    > (otoh, we could probably randomly delete ten old filesystems and
    > practically nobody would notice)

    I don't know how stable fuse APIs are (ie. whether we'd just be handing the
    anchors to FUSE), but if it is very stable, then it would be nice to push a
    lot of them out of the kernel (although OTOH the old ones tend not to have
    complex interactions with mm or block layer).



    \
     
     \ /
      Last update: 2009-01-07 03:25    [W:2.266 / U:0.104 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site