home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!uunet!not-for-mail
- From: iand@labtam.labtam.oz.au (Ian Donaldson)
- Newsgroups: comp.std.unix
- Subject: Re: File Locking across NFS mounts
- Date: 15 Sep 1992 13:46:23 -0700
- Organization: Labtam Australia Pty. Ltd., Melbourne, Australia
- Lines: 54
- Sender: sef@ftp.UU.NET
- Approved: sef@ftp.uucp (Moderator, Sean Eric Fagan)
- Message-ID: <195i2vINNjdf@ftp.UU.NET>
- References: <18omcgINN8tm@ftp.UU.NET> <18r014INN3ec@ftp.UU.NET>
- NNTP-Posting-Host: ftp.uu.net
- X-Submissions: std-unix@uunet.uu.net
-
- Submitted-by: iand@labtam.labtam.oz.au (Ian Donaldson)
-
- johnl@iecc.cambridge.ma.us (John R. Levine) writes:
- >Yeah. The problem is that although the NFS calls are all individually
- >idempotent, they aren't in combination, and there is no way to enforce
- >exactly-once semantics in NFS. Here's the classic example:
-
- >client server
-
- >creat("foo") ----------> truncates "foo"
- > +---------- ack creat
- > | slow network
- >creat("foo)" retry ---|------+
- >receive ack <---+ |
- >write data -----|---> writes data
- >receive ack <----|--- ack write
- > +---> truncates file again
- >discard dup response <--- ack creat
-
- >So all of the requests were executed and acked, but the repeated creat()
- >threw away the data. Oops.
-
- If each NFS_create transmission request had a different xid wouldn't this
- problem vanish? This is provided that you don't start writing until you
- get a response to the last request you sent (ie: ignoring arrivals
- of delayed earlier sent ones).
-
- Isn't the current problem that many NFS client implementations
- use clnt_call() once and it uses the same xid in each request it retransmits,
- and returns when it gets any response with a matching xid? Thus it doesn't
- know if there are any further requests still on the way to the server,
- because it can't tell which response it got.
-
- If a different xid is used in each request, the host wouldn't need
- to keep a cache of request-id's at all as each request would have
- a unique xid, and this would make the problem of the "state" that
- the server temporarily keeps about such requests, go away.
-
- The client would need to check for obvious errors in replies due to duplicated
- attempts to do things that change server state such as mkdir/rmdir/unlink/chown,
- due to lost replies from the server.
-
- Anyway, isn't this also only a problem with popular UDP based NFS
- implementations? With TCP this problem shouldn't exist.
-
- Ian Donaldson
-
- Email: iand@labtam.labtam.oz.au
- Phone: +61-3-587-1444
- Fax: +61-3-580-5581
-
- [ I think followups should go to comp.protocols.nfs -- mod ]
-
- Volume-Number: Volume 29, Number 38
-