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"