lkml.org 
[lkml]   [1997]   [Jan]   [3]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
From(Stephen R. van den Berg)
DateThu, 2 Jan 1997 23:24:41 +0100
SubjectRe: NFS Problem in Kernel 2.0.27: inode status not updated
Tim Wright <timw@sequent.com> wrote:
>[details deleted].
>In one word "NO".
>You cannot rely on ANY Unix filesystems semantics using NFSv2.

I agree that it's fairly bad.  But, if you make sure that you're the
only client operating on a certain file which has never existed before,
the results aren't so bad (if the NFS-client and server are a good quality
implementation).

>As I recall, one particularly entertaining scenario which would mess up
>the using link to lock follow:

Maybe he hasn't kept up with technology, but about six years ago
I already came up with an algorithm that outwits NFS (in this case).

>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.

That's what a traditional program would have thought, yes.  The locking
method I've been using in procmail (since 1991) works roughly as follows:

procmail		client			server

create unique new
file a (unique in time
and space) using
a regular open() call

						create file (a)

link(a,b)
			ask server to link(a,b)
						make link(a,b)
						server crashes, ack lost
						server comes back up
			retry link(a,b)
						file b already exists
						deny link, send back result
			link(a,b) failed,
			flush attribute cache
			for files a and b
			since they *may*
			be incorrect now
			(if link() had succeeded, best to flush the cache,
			or increase the st_nlink count by one; not that it
			really matters to procmail, since it skips the
			stat in that case)
link(a,b) returns
error

Procmail ignores the
"failed" return-code
because it knows it's
unreliable

stat(a)
			stat(a)
						stat(a)
						server crashes, ack lost
						server comes back up
			retry stat(a)
						return stat(a) results
			return stat(a)
Check st_nlink,
if it's equal to
two, the link(a,b)
succeeded.

unlink(a)
			....etc.

>The moral of this tale ?

Given the right algorithm, NFS can be outwitted (in some cases).

>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.

Hardly.  The TCP connection would simply have been broken in the
case of a server crash.  The link() will still succeed the first time.
Causing the same problem upon server recovery.

-- 
Sincerely,                                                          srb@cuci.nl
           Stephen R. van den Berg (AKA BuGless).

"-- hit any user to continue"

\
 
 \ /
  Last update: 2005-03-22 12:38    [from the cache]
©2003-2008