Re: [Avf-fuse-dev] Re: File locking

[Steven J. <py...@li...>]

Greetings,

I also have an interest in supporting locks that will not necessarily be
confined to a single machine.

On Fri, 8 Oct 2004, Miklos Szeredi wrote:

> > Ah, this rather precludes my use of FUSE.  I guess this goes back to
> > having fnctl control at the API level.
>
> Let's talk about this a bit.  Please correct me if I'm wrong
> somewhere, because I'm not an expert in this area.
>
> fcntl() anf lockf() provide interfaces for the same locking mechanism
> (at least on Linux), flock() is slightly different.  The kernel
> contains a default locking implementation for all of these, and the
> filesystem can implement it's own locking (like NFS) for the first
> kind.  flock() cannot be modified by the filesystem, so it's not
> supported on networked fs's.
>

Unfortunatly true. Supporting flock would require changes in the kernel.
Perhaps interesting, but I would rather not go there at this time. Since
flock already doesn't work over NFS, it won't surprise anyone when it
doesn't work over a FUSE based shared filesystem.

> So we're only interested in lockf() style locks.  These locks have
> byte granularity, so any byte range of a file can be locked (even
> beyond EOF).  Each range can be either read or write lock.  The locks
> are assigned to an inode, but they are also shared within a process.
> Locks are inherited across exec() but not across fork().  If a process
> closes any file refering to an inode previously locked by the same
> process (not just thread), all the locks on this inode owned by the
> process are removed.  This obvously also means that locks owned by a
> process are removed on exit.
>
> And if this wasn't complicated enough, there's another twist: applying
> a new lock to an already locked inode will behave differently in case
> the previous lock was done by the same thread (not process).  In this
> case the lock is not blocked (which would obviously cause a deadlock),
> but rather the range is changed to the new lock type, or just remains
> the same.  Locked ranges can be split or merged, this way.

This can probably be simplified a lot by restricting the FUSE filesystem
daemon's responsabilities here. The daemon can be responsible for locking
with a host granularity, and the kernel for deciding who on that host
owns the lock.

The more challenging part is handling cases where a process wants to sleep
until the lock is granted. We may not want to dedicate daemon threads to
sleeping until a lock can be granted.

>
> So if I understand correctly, you want to "transfer" any locks on the
> fuse mounted filesystem to NFS.  I can imagine two possibilities:
>
> 1) The fuse kernel module relays any locking operation to the
>    userspace filesystem, including information on the owner (some
>    abstract ID), and the thread ID (which we always refer to as pid).
>    And the userspace fs has to sort out the above rules, or somehow
>    delegate the locking to the underlying fs (as in your case).
>
> 2) Only the agregated locking is sent to the userspace fs.  Obviously,
>    this is harder (if at all possible) to implement in the kernel
>    part, but probably simplifies the userspace part.  I'd prefer this
>    solution but it would require woring out an interface with which
>    the above rules can be satisfied even in case of a networked
>    filesystem.

#2 is somewhat similar to my suggestion above now that I think about it
:-) It will be necessary to inform userspace of any operation that affects
what regions are locked so it can see if two locks on the same file would
overlap or not. However, like forget, unlocking a region wouldn't require
a reply.

>
> What do you think?  Can you help me with this?
>
> Miklos
>

G'day,
sjames

||||| |||| |||||||||||||  |||
by Linux Labs International, Inc.
   Steven James, CTO

55 Marietta Street
Suite 1830
Atlanta, Ga 30303
866 824 9737 support