🚀 go-pugleaf

Submitted-by: johnl@iecc.cambridge.ma.us (John R. Levine)

>Submitted-by: lebrun@ll.mit.edu ("Steven F. LeBrun")
>I am looking for a method of file locking what works across NFS
>mounted directories and am interested on what methods other 
>people are using.

You aren't likely to get very satisfactory results using record locking.
Many versions of the locking daemon don't work at all, and the crash
recovery seems to me to be hopelessly amateurish.  I've worked on projects
that tried to use record locking and even after doing six backflips to try
and work around the record locking bugs, at least to get to the point that
we didn't just hang if the locking daemon wasn't working, the results
still were not great.

The time-honored technique of using a directory as a semaphore and using
mkdir() and rmdir() as lock and unlock works fairly well, although it's
rather slow.  Using link() and unlink() also works, at least on systems
that use the Unix semantics that you can't link on top of an existing
file.

If you're serious about having the locks work, in the long run you'll get
much better results if you write your own daemon that listens to a TCP/IP
socket and handles reserve and release messages, or maybe even manages the
file itself and accepts requests to atomically update and read from the
file.

Regards,
John Levine, johnl@iecc.cambridge.ma.us, {spdcc|ima|world}!iecc!johnl


Volume-Number: Volume 29, Number 22

Submitted-by: henry@zoo.toronto.edu (Henry Spencer)

>Submitted-by: johnl@iecc.cambridge.ma.us (John R. Levine)
>The time-honored technique of using a directory as a semaphore and using
>mkdir() and rmdir() as lock and unlock works fairly well, although it's
>rather slow...

It isn't reliable, however.  The crucial point is that NFS does not provide
a sufficiently good imitation of Unix filesystem semantics.  I'm told -- I
have not seen details and don't have a reference -- that if you look hard
enough at the problem, and consider things like finite cache sizes, you
can prove that there is *no way* to do reliable locking through the NFS
protocol.  You have to use some sort of non-filesystem method, like
locking daemons (and I agree with John that writing your own is the best
method; the existing ones are garbage).

This is one reason (of many) why proposals to canonize NFS as a standard
weren't greeted with cries of delight from all directions...
-- 
There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
mistakes, but... make *new* ones. -D.Sim|  henry@zoo.toronto.edu  utzoo!henry


Volume-Number: Volume 29, Number 30

Submitted-by: johnl@iecc.cambridge.ma.us ("John R. Levine")

>Submitted-by: lebrun@ll.mit.edu ("Steven F. LeBrun")
>I am looking for a method of file locking what works across NFS
>mounted directories and am interested on what methods other 
>people are using.

You aren't likely to get very satisfactory results using record locking.
Many versions of the locking daemon don't work at all, and the crash
recovery seems to me to be hopelessly amateurish.  I've worked on projects
that tried to use record locking and even after doing six backflips to try
and work around the record locking bugs, at least to get to the point that
we didn't just hang if the locking daemon wasn't working, the results
still were not great.

The time-honored technique of using a directory as a semaphore and using
mkdir() and rmdir() as lock and unlock works fairly well, although it's
rather slow.  Using link() and unlink() also works, at least on systems
that use the Unix semantics that you can't link on top of an existing
file.

If you're serious about having the locks work, in the long run you'll get
much better results if you write your own daemon that listens to a TCP/IP
socket and handles reserve and release messages, or maybe even manages the
file itself and accepts requests to atomically update and read from the
file.

Regards,
John Levine, johnl@iecc.cambridge.ma.us, {spdcc|ima|world}!iecc!johnl


Volume-Number: Volume 29, Number 31