[lkml]   [2005]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [Linux-cluster] Re: GFS, what's remaining
    On Sunday 04 September 2005 00:46, Andrew Morton wrote:
    > Daniel Phillips <> wrote:
    > > The model you came up with for dlmfs is beyond cute, it's downright
    > > clever.
    > Actually I think it's rather sick. Taking O_NONBLOCK and making it a
    > lock-manager trylock because they're kinda-sorta-similar-sounding? Spare
    > me. O_NONBLOCK means "open this file in nonblocking mode", not "attempt to
    > acquire a clustered filesystem lock". Not even close.

    Now, I see the ocfs2 guys are all ready to back down on this one, but I will
    at least argue weakly in favor.

    Sick is a nice word for it, but it is actually not that far off. Normally,
    this fs will acquire a lock whenever the user creates a virtual file and the
    create will block until the global lock arrives. With O_NONBLOCK, it will
    return, erm... ETXTBSY (!) immediately. Is that not what O_NONBLOCK is
    supposed to accomplish?

    > It would be much better to do something which explicitly and directly
    > expresses what you're trying to do rather than this strange "lets do this
    > because the names sound the same" thing.
    > What happens when we want to add some new primitive which has no posix-file
    > analog?
    > Waaaay too cute. Oh well, whatever.

    The explicit way is syscalls or a set of ioctls, which he already has the
    makings of. If there is going to be a userspace api, I would hope it looks
    more like the contents of userdlm.c than the traditional Vaxcluster API,
    which sucks beyond belief.

    Another explicit way is to do it with a whole set of virtual attributes
    instead of just a single file trying to capture the whole model. That is
    really unappealing, but I am afraid that is exactly what a whole lot of
    sysfs/configfs usage is going to end up looking like.

    But more to the point: we have no urgent need for a userspace dlm api at the
    moment. Nothing will break if we just put that issue off for a few months,
    quite the contrary.

    If the only user is their tools I would say let it go ahead and be cute, even
    sickeningly so. It is not supposed to be a general dlm api, at least that is
    my understanding. It is just supposed to be an interface for their tools.
    Of course it would help to know exactly how those tools use it. Too sleepy
    to find out tonight...


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-09-04 08:43    [W:0.022 / U:46.956 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site