home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / std / unix / 426 < prev    next >
Encoding:
Internet Message Format  |  1992-09-15  |  2.6 KB
  1. Path: sparky!uunet!uunet!not-for-mail
  2. From: iand@labtam.labtam.oz.au (Ian Donaldson)
  3. Newsgroups: comp.std.unix
  4. Subject: Re: File Locking across NFS mounts
  5. Date: 15 Sep 1992 13:46:23 -0700
  6. Organization: Labtam Australia Pty. Ltd., Melbourne, Australia
  7. Lines: 54
  8. Sender: sef@ftp.UU.NET
  9. Approved: sef@ftp.uucp (Moderator, Sean Eric Fagan)
  10. Message-ID: <195i2vINNjdf@ftp.UU.NET>
  11. References: <18omcgINN8tm@ftp.UU.NET> <18r014INN3ec@ftp.UU.NET>
  12. NNTP-Posting-Host: ftp.uu.net
  13. X-Submissions: std-unix@uunet.uu.net
  14.  
  15. Submitted-by: iand@labtam.labtam.oz.au (Ian Donaldson)
  16.  
  17. johnl@iecc.cambridge.ma.us (John R. Levine) writes:
  18. >Yeah.  The problem is that although the NFS calls are all individually
  19. >idempotent, they aren't in combination, and there is no way to enforce
  20. >exactly-once semantics in NFS.  Here's the classic example:
  21.  
  22. >client                    server
  23.  
  24. >creat("foo")          ---------->    truncates "foo"
  25. >              +----------       ack creat
  26. >              | slow network
  27. >creat("foo)" retry ---|------+
  28. >receive ack       <---+      |
  29. >write data        -----|--->      writes data
  30. >receive ack             <----|---       ack write
  31. >                 +--->    truncates file again
  32. >discard dup response         <---    ack creat
  33.  
  34. >So all of the requests were executed and acked, but the repeated creat()
  35. >threw away the data.  Oops.
  36.  
  37. If each NFS_create transmission request had a different xid wouldn't this 
  38. problem vanish?  This is provided that you don't start writing until you 
  39. get a response to the last request you sent (ie: ignoring arrivals
  40. of delayed earlier sent ones).
  41.  
  42. Isn't the current problem that many NFS client implementations
  43. use clnt_call() once and it uses the same xid in each request it retransmits,
  44. and returns when it gets any response with a matching xid?  Thus it doesn't
  45. know if there are any further requests still on the way to the server,
  46. because it can't tell which response it got.
  47.  
  48. If a different xid is used in each request, the host wouldn't need
  49. to keep a cache of request-id's at all as each request would have
  50. a unique xid, and this would make the problem of the "state" that
  51. the server temporarily keeps about such requests, go away.  
  52.  
  53. The client would need to check for obvious errors in replies due to duplicated
  54. attempts to do things that change server state such as mkdir/rmdir/unlink/chown,
  55. due to lost replies from the server.
  56.  
  57. Anyway, isn't this also only a problem with popular UDP based NFS 
  58. implementations?  With TCP this problem shouldn't exist.  
  59.  
  60. Ian Donaldson
  61.  
  62. Email:  iand@labtam.labtam.oz.au
  63. Phone:  +61-3-587-1444
  64. Fax:    +61-3-580-5581
  65.  
  66. [ I think followups should go to comp.protocols.nfs -- mod ]
  67.  
  68. Volume-Number: Volume 29, Number 38
  69.