Messages in this thread |  | | Subject | Re: NFS Problem in Kernel 2.0.27: inode status not updated | Date | Thu, 02 Jan 1997 09:48:54 PST | From | Tim Wright <> |
| |
[details deleted]. In one word "NO". You cannot rely on ANY Unix filesystems semantics using NFSv2.
Jim Reid of Strathclyde University put together an excellent paper on the evils of NFS for the UKUUG 1990 summer conference (the Plan 9 one).
As I recall, one particularly entertaining scenario which would mess up the using link to lock follow:
CLIENT SERVER
sends request link(fileA, fileB) receives request fileA exists, fileB does not server performs link and returns success.
reply is lost and client does not see it
Client re-sends the request to link fileA to fileB server again receives the request Both fileA and fileB exist link fails. Server replies This time the client receives the reply. The client believes that the link failed (i.e. it was already locked), but in fact it succeeded.
The moral of this tale ?
Don't expect too much of NFS (and almost anything is too much). It was a quick and nasty hack. It was implemented over the wrong transport because, at the time, Sun's TCP performance sucked (a problem that was subsequently addressed). Had it used TCP, a lot of the out of order nonsense would not be an issue.
Sigh.
t
-- Tim Wright, Worldwide Technical Services, | Email: timw@sequent.com Sequent Computer Systems Inc., 15450, | SW Koll Parkway, Beaverton, Oregon 97006 | Phone: +1-503-578-3822 "Applying computer technology is simply finding the right wrench to pound in the correct screw"
|  |