[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gfs-devel
Subject:    file locking blues.
From:       Mike Tilstra <tilstra () lcse ! umn ! edu>
Date:       1999-09-07 17:17:28
[Download RAW message or body]

I'm going to put my reason for posting this up here, so you don't have
to read the whole thing to know why.  I would like to get opinions from
people that actually are or would use file locking.  This affects you
most, so I'd like to hear back.

  ---

I am trying to get file locking put into gfs.  For starters we are
going to support the flock command. (not locking through the fcntl cmd).
We are starting with this because it locks an entire file, not ranges
like fcntl can. (which is much more difficult.)

I've added a place into the files' inode, and for nonblocking calls this
works just fine. (I tested it across two systems.)  The complex part comes
for a blocking version of the command.  The most straight forward method
is to continually grab the glocks (which become dlocks) for the inode,
and look at it.  This is a problem because if someone else is writing
to that file, they must continually flush their cache, and drop the lock
to at least the shared state.  This continual interruption of the write
would blow your performance (and thus is an icky solution).

Now, if we lived in a land where the dlocks were plenty.  And every
inode could have two or three instead of having to share, we could just
use a dlock for the file lock operations.  This would be a wonderfully
nice solution.  What makes this so nice is that all of the locking
problems have been solved for gfs and if we could use them for file
locks, we wouldn't have to recreate most of the solutions.  If dlocks
were plentiful, which they're not.

A variation of this would be to set off a small range of dlocks for
file locking.  To lock a file, gfs would grab one of these extra locks,
assign it to the file as a file lock, and lock it.  There would be a
single interruption when a client first looks up the dlock for the file
lock, then this info would be cached, and the remaining look ups would
not interrupt the file.  If a client trys to lock a file, and all of the
dlocks that can be used for file locks are taken, then the client would
get an error.  There would need to be some method of adjusting the number
of locks set aside for file locks, since some uses of gfs won't need any,
and other will need plenty.

Writing this up I thought of a possible variation on the first (icky)
solution.  What if the flock unlock command forces a release of the glock.
Then others just need to poll the inodes' glock to see if it is busy.
Once it is avail, they can grab it to check the file lock.  This could
work, but I imagine introduces some problems. (mostly from multiple
inodes on the same dlock.)

Well, that's what I know about it.
Opinions?
-- 
Mike Tilstra                          tilstra@lcse.umn.edu
Some people live life in the fast lane. You're in oncoming traffic.

To unsubscribe from this list: send the line "unsubscribe gfs-devel" in
the body of a message to majordomo@lcse.umn.edu

[prev in list] [next in list] [prev in thread] [next in thread]