lkml.org 
[lkml]   [2008]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/7] OMFS filesystem version 3
    On Mon, Apr 14, 2008 at 10:20 AM, Chris Mason <chris.mason@oracle.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


    \
     
     \ /
      Last update: 2008-04-14 18:39    [W:5.439 / U:0.148 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site