🚀 go-pugleaf

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

>>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...

>Submitted-by: henry@zoo.toronto.edu (Henry Spencer)
>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.

Yeah.  The problem is that although the NFS calls are all individually
idempotent, they aren't in combination, and there is no way to enforce
exactly-once semantics in NFS.  Here's the classic example:

client					server

creat("foo")          ---------->	truncates "foo"
		      +----------       ack creat
		      | slow network
creat("foo)" retry ---|------+
receive ack       <---+      |
write data		-----|--->      writes data
receive ack             <----|---   	ack write
			     +--->	truncates file again
discard dup response         <---	ack creat

So all of the requests were executed and acked, but the repeated creat()
threw away the data.  Oops.

This apparently was a real problem, according to a paper at Usenix a few
years ago.  Sun has added a request cache and discards any request that is
a duplicate of one in the cache, but you can only keep requests for a few
seconds in a reasonable sized cache, and long-haul networks can easily
have delays longer than that. 

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


Volume-Number: Volume 29, Number 32