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