Message-ID: <b6c5339f0804140936s3dcce48en59a270dc86bf7dc8@mail.gmail.com>
Date:	Mon, 14 Apr 2008 12:36:54 -0400
From:	"Bob Copeland" <me@...copeland.com>
To:	"Chris Mason" <chris.mason@...cle.com>
Cc:	"Christoph Hellwig" <hch@...radead.org>,
	"Alan Cox" <alan@...rguk.ukuu.org.uk>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"David Woodhouse" <dwmw2@...radead.org>,
	"Miklos Szeredi" <miklos@...redi.hu>, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 0/7] OMFS filesystem version 3

On Mon, Apr 14, 2008 at 10:20 AM, Chris Mason <chris.mason@...cle.com> wrote:
>  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.

Sure, no worries...

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

The recent deprecation of iget was probably the most involved of any.  It
wasn't that bad, but the #ifdef jungle going back to at least .17 is getting
somewhat hairy (I have 19 of them).  I would say over the past year or so
most of the changes have been <10 liners with kmem_cache_* interface changes.
Luckily through review here, that got zapped anyway.

In the normal case, I'll grab an -rc3 kernel or so, try to compile it, if
it fails, look at minix to see the minimum set of changes I need to make.
The challenge for me maintaining it out-of-tree is that sometimes the git
logs do not carry enough context to know why XYZ changed and if there's a
better, new way to do things.  Then it's time to scour the mailing lists.

>  So, there are two big questions I'd ask:
>
>  * Which setup (kernel or fuse) would Bob find easier to maintain things?
>  * Is this a first step toward more development and an increased user base?

Well, FUSE is easier from the standpoint of having somewhat more control.
On the other hand, that also results in an inferior product if it isn't given
the many-eyes treatment.  For the code itself, it's really not that much
different since FUSE is so close to the VFS API anyway.

For your second question:

More users are always welcome.  At present, the FUSE version implements a few
things that the kernel module does not - better/different block allocation
algorithm, growing truncate, automatic byte-swapping for the ReplayTV model
that had a busted block layer.  However, the FUSE version is known to be buggy
with respect to every day use (I had one MD5 fail among 20G of files in one
copy test).

I could see adding 1 and 2 to the kernel version, but probably not the
byte-swapping bit.  I'm not sure what to do from there on.

As a user, I use the kernel module because it works, it's faster, and the
other bells and whistles aren't that important to me.  It's hard to tell
what the user community prefers, because the kernel module was first and
so far no one has had a reason to try the FUSE implementation (if they
have, I don't know about it).

-- 
Bob Copeland %% www.bobcopeland.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists