home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / std / unix / 410 < prev    next >
Encoding:
Internet Message Format  |  1992-09-09  |  1.9 KB
  1. Xref: sparky comp.std.unix:410 comp.unix.programmer:4596
  2. Path: sparky!uunet!uunet!not-for-mail
  3. From: johnl@iecc.cambridge.ma.us (John R. Levine)
  4. Newsgroups: comp.std.unix,comp.unix.programmer
  5. Subject: Re: File Locking across NFS mounts
  6. Followup-To: comp.unix.programmer
  7. Date: 9 Sep 1992 14:18:37 -0700
  8. Organization: I.E.C.C.
  9. Lines: 32
  10. Sender: sef@ftp.UU.NET
  11. Approved: sef@ftp.uucp (Moderator, Sean Eric Fagan)
  12. Message-ID: <18lpndINN8ti@ftp.UU.NET>
  13. References: <18j4hdINNdst@ftp.UU.NET>
  14. NNTP-Posting-Host: ftp.uu.net
  15. X-Submissions: std-unix@uunet.uu.net
  16.  
  17. Submitted-by: johnl@iecc.cambridge.ma.us (John R. Levine)
  18.  
  19. >Submitted-by: lebrun@ll.mit.edu ("Steven F. LeBrun")
  20. >I am looking for a method of file locking what works across NFS
  21. >mounted directories and am interested on what methods other 
  22. >people are using.
  23.  
  24. You aren't likely to get very satisfactory results using record locking.
  25. Many versions of the locking daemon don't work at all, and the crash
  26. recovery seems to me to be hopelessly amateurish.  I've worked on projects
  27. that tried to use record locking and even after doing six backflips to try
  28. and work around the record locking bugs, at least to get to the point that
  29. we didn't just hang if the locking daemon wasn't working, the results
  30. still were not great.
  31.  
  32. The time-honored technique of using a directory as a semaphore and using
  33. mkdir() and rmdir() as lock and unlock works fairly well, although it's
  34. rather slow.  Using link() and unlink() also works, at least on systems
  35. that use the Unix semantics that you can't link on top of an existing
  36. file.
  37.  
  38. If you're serious about having the locks work, in the long run you'll get
  39. much better results if you write your own daemon that listens to a TCP/IP
  40. socket and handles reserve and release messages, or maybe even manages the
  41. file itself and accepts requests to atomically update and read from the
  42. file.
  43.  
  44. Regards,
  45. John Levine, johnl@iecc.cambridge.ma.us, {spdcc|ima|world}!iecc!johnl
  46.  
  47.  
  48. Volume-Number: Volume 29, Number 22
  49.