home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / std / unix / 420 < prev    next >
Encoding:
Internet Message Format  |  1992-09-11  |  2.2 KB
  1. Path: sparky!uunet!uunet!not-for-mail
  2. From: johnl@iecc.cambridge.ma.us (John R. Levine)
  3. Newsgroups: comp.std.unix
  4. Subject: Re: File Locking across NFS mounts
  5. Date: 11 Sep 1992 13:36:52 -0700
  6. Organization: I.E.C.C.
  7. Lines: 45
  8. Sender: sef@ftp.UU.NET
  9. Approved: sef@ftp.uucp (Moderator, Sean Eric Fagan)
  10. Message-ID: <18r014INN3ec@ftp.UU.NET>
  11. References: <18omcgINN8tm@ftp.UU.NET>
  12. NNTP-Posting-Host: ftp.uu.net
  13. X-Submissions: std-unix@uunet.uu.net
  14.  
  15. Submitted-by: johnl@iecc.cambridge.ma.us (John R. Levine)
  16.  
  17. >>Submitted-by: johnl@iecc.cambridge.ma.us (John R. Levine)
  18. >>The time-honored technique of using a directory as a semaphore and using
  19. >>mkdir() and rmdir() as lock and unlock works fairly well, although it's
  20. >>rather slow...
  21.  
  22. >Submitted-by: henry@zoo.toronto.edu (Henry Spencer)
  23. >It isn't reliable, however.  The crucial point is that NFS does not provide
  24. >a sufficiently good imitation of Unix filesystem semantics.  I'm told -- I
  25. >have not seen details and don't have a reference -- that if you look hard
  26. >enough at the problem, and consider things like finite cache sizes, you
  27. >can prove that there is *no way* to do reliable locking through the NFS
  28. >protocol.
  29.  
  30. Yeah.  The problem is that although the NFS calls are all individually
  31. idempotent, they aren't in combination, and there is no way to enforce
  32. exactly-once semantics in NFS.  Here's the classic example:
  33.  
  34. client                    server
  35.  
  36. creat("foo")          ---------->    truncates "foo"
  37.               +----------       ack creat
  38.               | slow network
  39. creat("foo)" retry ---|------+
  40. receive ack       <---+      |
  41. write data        -----|--->      writes data
  42. receive ack             <----|---       ack write
  43.                  +--->    truncates file again
  44. discard dup response         <---    ack creat
  45.  
  46. So all of the requests were executed and acked, but the repeated creat()
  47. threw away the data.  Oops.
  48.  
  49. This apparently was a real problem, according to a paper at Usenix a few
  50. years ago.  Sun has added a request cache and discards any request that is
  51. a duplicate of one in the cache, but you can only keep requests for a few
  52. seconds in a reasonable sized cache, and long-haul networks can easily
  53. have delays longer than that. 
  54.  
  55. Regards,
  56. John Levine, johnl@iecc.cambridge.ma.us, {spdcc|ima|world}!iecc!johnl
  57.  
  58.  
  59. Volume-Number: Volume 29, Number 32
  60.