On Mon, 14 Apr 2008, Chris Mason wrote:

quoted text
> On Monday 14 April 2008, Christoph Hellwig wrote:
>> On Mon, Apr 14, 2008 at 09:16:39AM +0100, Alan Cox wrote:
>>> I think the exceed them quite easily. The costs are almost nil, while
>>> merging this provides another nice example fs (and one much easier to
>>> follow than ext*) for hardware that does have a few users and will no
>>> doubt get many more
>>>
>>> I wasn't aware Linus had introduced a new rule required 500 people sign
>>> up to use a feature before it gets added ?
>>
>> I'm also very surprised by this, especially as it seems to be applied
>> very selectively.  This filesystems is an almost 0 maintainance burden
>> unlike a lot of really crappy driver we're shoving in constantly.
>
> Thanks to Bob Copeland for taking the time to submit this for mainline.
> Please don't mistake the resulting debate as a sign we don't appreciate the
> effort of making it available and getting it reviewed.

seconded.

quoted text
> Unlike all the device drivers we don't want floating around out of the tree,
> filesystem authors do have a choice between FUSE and being in-kernel.  Since
> OMFS has been maintained out of tree since 2.6.12 or so, Bob probably has a
> very good idea of how much time he has needed to spend updating things for
> each release.

switching to FUSE also has a cost for users, namely that they need to have 
FUSE setup (and the various interactions and deadlocks that can happen 
with a userspace filesystem, such as swapping to it)

as a user I would prefer to see filesystems (even ones I don't expect to 
uer) be all treated the same way, not have to figure out that to use this 
list of filesystems I configure them in the kernel, and to use that list 
of filesystem I have to run FUSE.

for testing, or for things that aren't really filesystems (views into 
version control systems, tarballs, etc) FUSE is a good match.

but for real filesystems it's a poor second.

David Lang

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html