DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com.au;
  h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:From:To:Subject:Date:User-Agent:Cc:References:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Disposition:Message-Id;
  b=TzLkhOqXTtmEKE1CwizSZJTpJHvjBHSTOl4Ly4XuH1RX9m5+7IGIN9LRJpnQgFYPovkmhD6fkQLYrLbFcyHWMZ0dld5RR7v2wCV26KpO72qbVjapwWOuHqtSOj67kBJ3WHCQbbJKPi9XsRUoD7Al89C+XhOUSRjS/zeCbIBwXUw=  ;
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Andrew Morton <akpm@linux-foundation.org>, linux-fsdevel@vger.kernel.org
Subject: Re: 2.6.29 -mm merge plans
Date: Wed, 7 Jan 2009 13:21:42 +1100
User-Agent: KMail/1.9.51 (KDE/4.0.4; ; )
Cc: Christoph Hellwig <hch@infradead.org>, linux-kernel@vger.kernel.org,
       Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
References: <20090105004300.19ed52d1.akpm@linux-foundation.org> <20090106225744.GA10553@infradead.org> <20090106152829.43dab4a0.akpm@linux-foundation.org>
In-Reply-To: <20090106152829.43dab4a0.akpm@linux-foundation.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200901071321.43068.nickpiggin@yahoo.com.au>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2136
Lines: 48

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

--
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/