[wplug] Python and file locking - NFS or MySQL?

Patrick Wagstrom pwagstro at andrew.cmu.edu
Fri Aug 26 09:12:48 EDT 2005


On Thu, 2005-08-25 at 22:18 -0400, Christopher DeMarco wrote:
> 1.  fcntl(2) is claimed to work "mostly" over NFS v >= 3.

Not sure about this, but it seems like it would be highly dependent on
the remote NFS server.  Always err on the side of borkage.

> 2.  open(2) is atomic on a local FS, I've read discussions that imply
> that link(2) is atomic over NFS (is it?), so I can link from local
> lockfile to remote target atomically.  I don't grok this; open(2) +
> link(2) + stat(2) == 3 calls on my fingers.  HTH is this supposed to
> work?

See above comment.  I would never trust anything to be atomic over NFS.

> 3.  Atomically update a MySQL database indicating that the file is
> locked - MySQL has atomic transactions now, right?  And how good is
> the Python MySQL API - IIRC Perl didn't have atomic transactions last
> year; will this work in contemporary Python?

With PostgreSQL and Python, anything in a transaction should be handled
as one atomic action, meaning that they'll all succeed or all fail.  One
of the niceities of the Python DBAPI is that transactions are
automagically started when a cursor is made and stopped when db.commit()
is run.  If your SQL-Fu is up to snuff, this seems like the way to go.
However, I'm not sure about MySQL atomicness.  See my first comment
about borkage.

Four or five years ago when I was working at a national lab, we
encountered a similar problem.  We had a very large shared file system
(several terrabytes) and needed locking of files, but it wasn't
necessarily heavy I/O.  We coded up a single threaded server process
that would manage which client had what file open.  Before opening the
file, the client called a command to request the data from the server.
If the file was already locked the server responded that it would call
the client back when the file was unlocked and then added the client to
a list of clients waiting on the file.  Thus, the client call didn't
return until the server said no one else had the file open.

It was a hack, but it worked well enough.  However, when folks tried to
expand the system to clients that needed locks on multiple files, we
found that some processes could easily be starved out.  ::shrug:: A
little more coding might have helped at that point, but you start
dealing with deadlock and other fun stuff at the same time then too.

--Patrick




More information about the wplug mailing list