lkml.org 
[lkml]   [1997]   [Jan]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: NFS Problem in Kernel 2.0.27: inode status not updated
Date
From
[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"



\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.089 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site