NFS puzzles (e.g. when client and server times don't match?)

NFS puzzles (e.g. when client and server times don't match?)

Post by Mark Aitchis » Thu, 13 Feb 1997 04:00:00



I posted some details about wierd problems between Linux and Solaris
before; thanks to help from Cameron MacKinnon I've been able to
eliminate some red herrings, and now I'm down to some suspicions about
nfs...

(1) If the nfs client and server have their times out by a few minutes,
what is the effect on nfs? (I think I had a problem years ago when the
time varied by more than this, at which time I got the idea that nfs
must need the times synchronised. Seem a bit surprising; can anybody
say yea or nay?)

(2) Solaris nfs changed considerably at version 2.5, at which time I
diagnosed a problem (which now seems to have been fixed in a patch from
Sun) where a status response that is lost (e.g. on a busy net?) caused
not one but many nfs timeout errors due to the response for the *next*
status request being gobbled up as the response to the earlier one -
that next request seeming to go unanswered until the next request, etc.
I don't know what the patch fixed, but the nfs between the solaris
machines stopped generating lots of erors, but I wonder if nfs between
solaris and other systems could still suffer from such a problem?

(3) Are there any known bugs with Solaris 2.5 nfs (or automount
especially) or with Linux (Slackware 3.1 or RedHat 4/SMP 2.0.28)??
In particular, what could make a linux rpc.nfsd run at 99.2% CPU on
a PPro 200??

-------------------------------------------------------------------------------
Mark Aitchison, Physics & Astronomy   \_  Phone : +64 3 3642-947 a.h. 3371-225
University of Canterbury,             </  Fax   : +64 3 3642-469  or  3642-999

#include <disclaimer.std>           (/'   "per haps ad gloria"
-------------------------------------------------------------------------------

 
 
 

NFS puzzles (e.g. when client and server times don't match?)

Post by Casper H.S. Dik - Network Security Engine » Thu, 13 Feb 1997 04:00:00



>(1) If the nfs client and server have their times out by a few minutes,
>what is the effect on nfs? (I think I had a problem years ago when the
>time varied by more than this, at which time I got the idea that nfs
>must need the times synchronised. Seem a bit surprising; can anybody
>say yea or nay?)

It should work, execpt for secure NFS which needs to have synchronised
clocks (or atleast the ability to find the time difference).

You will see strange times listed on the client; the time is typically
not set by the client but set as a side effect of the server writing/reading
the file.  So "touch xxx" will give the servers current time as
creastion time.  ls may get confused by times in future and print
in Month day Year format rather than Month day time"

Make should still work as all times are set on the server and consistent.

Quote:>(3) Are there any known bugs with Solaris 2.5 nfs (or automount
>especially) or with Linux (Slackware 3.1 or RedHat 4/SMP 2.0.28)??
>In particular, what could make a linux rpc.nfsd run at 99.2% CPU on
>a PPro 200??

It seems to me that if the linux rpc.nfsd goes into a 99% CPU use
mode that it has a bug (both client and server implementations shoul
be prepared to accept any bogus stuff thrown at them; so if the 99% CPU
use doesn't go hand in hand with *lots* of NFS requests, something is
amiss in Linux nfsd)

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

 
 
 

NFS puzzles (e.g. when client and server times don't match?)

Post by Jim Rei » Thu, 13 Feb 1997 04:00:00



> (1) If the nfs client and server have their times out by a few minutes,
> what is the effect on nfs? (I think I had a problem years ago when the
> time varied by more than this, at which time I got the idea that nfs
> must need the times synchronised. Seem a bit surprising; can anybody
> say yea or nay?)

NFS itself doesn't care at all about the client's and server's notion
of time. Some of the RPC mechanisms that NFS uses do: AUTH_DES (and
AUTH_KERB?) include a timestamp in the authentication token. This
timestamp is intended to thwart replay attacks and the like. If the
client and server disagree about the time by "too much" - say a few
seconds - the authentication tokens are rejected because the
timestamps are too different and NFS access is denied.

If the client and server disagree about the time, there are a few
subtle problems. Timestamps on inodes may be misinterpreted,
preventing recently modified or accessed files from being processed
properly. [ie. makes or finds and backup scripts on the client don't
do what was expected as they consider the file(s) that have just been
changed as "old".] Also, ranlib (if you have it) writes a timestamp
into the library. If you run this on a client with a clock that's
behind the server's, you can get warnings at link time because the
linker thinks the library has been updated (server's mtime in the
inode) and ranlib has not been run (client's time in the library's
internal timestamp).

 
 
 

NFS puzzles (e.g. when client and server times don't match?)

Post by Vernon Schryv » Thu, 13 Feb 1997 04:00:00




Quote:> ...
>>(1) If the nfs client and server have their times out by a few minutes,
>>what is the effect on nfs? ...
>Make should still work as all times are set on the server and consistent.

That's true, except for the decisions that `make` computes based on
the mtimes that it thinks that targets will get as the result of rules,
or when it is comparing mtimes to "now".

In other words, no, `make` does not work if the NFS client and server
have significantly different notions of the current time.  A time skew
of as little as a few seconds is enough to mess up `make`.  If you
are running `make` with files on different file systems, such as
building binaries in local file systems using NFS mounted source,
`make` becomes very insane.  The most common failures in my experience
are either `make` refusing to rebuild something that needs it, or
insisting on rebuilding something that doesn't.

`timed`, NTP, and even `rdate` are your friends.


 
 
 

1. match works, don't match doesn't

@cts.com
Organization: CTS Network Services
Mime-Version: 1.0

Newsgroups: comp.unix.programmer

The following is supposed to search an input file and produce 2 output
files. The input file consists of text lines of two fields, delimited
by whitespace. The first output file is to contain those lines in the
input file where any one of the variable strings match the first
field. (This works.) The second output file is to contain those lines
where the variable strings do not match, i.e. all the lines in the
input file except those found with the first search. (This doesn't
work.)

###command-line parameter placed in variable.###


   searchdot="\.$1"
   searchexact=$1

awk '{IGNORECASE=1} $1 ~ /'^"$searchexact"$'/ || /'"$searchat"'/ ||
/'"$searchdot"'/ { print $0 }' input.file > output1.file

awk '{IGNORECASE=1} $1 !~ /'^"$searchexact"$'/ || /'"$searchat"'/ ||
/'"$searchdot"'/ { print $0 }' input.file > output2.file

Any help gratefully accepted.  

2. Is gnome normally this slow?

3. NFS clients don't follow mount point on server to correct file system device

4. Disasterous HD crash

5. how to stop nfs server and don't reboot the clients ??

6. : Masquerade

7. nfs clients don't see other mounts under nfs export

8. semctl BSD/Linux

9. Down 'Solaris' NFS Server hangs 'Solaris' Client

10. why don't write file in the nfs of win client????

11. Mounted hard drives don't show up on NFS clients.

12. NFS clients don't recover from network outage

13. Exported directories don't appear on NT NFS client