home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.29 / text0030.txt < prev    next >
Encoding:
Text File  |  1992-12-26  |  1.8 KB  |  47 lines
  1. Submitted-by: johnl@iecc.cambridge.ma.us (John R. Levine)
  2.  
  3. >>Submitted-by: johnl@iecc.cambridge.ma.us (John R. Levine)
  4. >>The time-honored technique of using a directory as a semaphore and using
  5. >>mkdir() and rmdir() as lock and unlock works fairly well, although it's
  6. >>rather slow...
  7.  
  8. >Submitted-by: henry@zoo.toronto.edu (Henry Spencer)
  9. >It isn't reliable, however.  The crucial point is that NFS does not provide
  10. >a sufficiently good imitation of Unix filesystem semantics.  I'm told -- I
  11. >have not seen details and don't have a reference -- that if you look hard
  12. >enough at the problem, and consider things like finite cache sizes, you
  13. >can prove that there is *no way* to do reliable locking through the NFS
  14. >protocol.
  15.  
  16. Yeah.  The problem is that although the NFS calls are all individually
  17. idempotent, they aren't in combination, and there is no way to enforce
  18. exactly-once semantics in NFS.  Here's the classic example:
  19.  
  20. client                    server
  21.  
  22. creat("foo")          ---------->    truncates "foo"
  23.               +----------       ack creat
  24.               | slow network
  25. creat("foo)" retry ---|------+
  26. receive ack       <---+      |
  27. write data        -----|--->      writes data
  28. receive ack             <----|---       ack write
  29.                  +--->    truncates file again
  30. discard dup response         <---    ack creat
  31.  
  32. So all of the requests were executed and acked, but the repeated creat()
  33. threw away the data.  Oops.
  34.  
  35. This apparently was a real problem, according to a paper at Usenix a few
  36. years ago.  Sun has added a request cache and discards any request that is
  37. a duplicate of one in the cache, but you can only keep requests for a few
  38. seconds in a reasonable sized cache, and long-haul networks can easily
  39. have delays longer than that. 
  40.  
  41. Regards,
  42. John Levine, johnl@iecc.cambridge.ma.us, {spdcc|ima|world}!iecc!johnl
  43.  
  44.  
  45. Volume-Number: Volume 29, Number 32
  46.  
  47.