Just how reliable is NFS?

Jim Reid jim at cs.strath.ac.uk
Thu Sep 11 21:06:56 AEST 1986


In article <2428 at phri.UUCP> roy at phri.UUCP (Roy Smith) writes:
>	Clearly, UDP is not suitable for times when you really care if the
>data gets delivered or not (rwho uses UDP, doesn't it?).  As I understand
>it, NFS uses UDP as the underlying transport protocol but to improve
>performance, Sun has turned off checksumming in NSF/UDP packets.
>Presumably NFS does its own error checking at a higher level, so they can
>get away with ignoring checksums at the lower levels.

UDP checksumming is switched off - but not just for performance reasons. I
understand that some implementations can't calculate the checksums properly
anyway. There has been some discussion of this in mod.protocols.tcp-ip.

There is no "higher-level" checking that I'm aware of. Presumably, you
can get away with the IP checksums and the ethernet frame checksums in the
IP fragments when constructing a UDP packet that comes in off the net.

If there were corruption problems, these should show up as errors in NFS
"headers" - RPC structures, file handles, and so on. The kernel would
scream about these if and when they happened.

>	Has anybody done any studies to determine if this causes any
>problems?  I've heard random comments by people on the net that they don't
>like what Sun did, but has anybody taken a serious look at the situation
>and found cases where corrupted UDP packets have caused user-visible NFS
>errors?  On the other hand, has anybody made any measurements to see just
>how much NFS would be slowed down if UDP checksumming were turned back on?

We've had no problems - mind you, we've not been actively looking for them.
Our users would be complaining if they found their files corrupted. So far
there have been no complaints. Turning on (or off) UDP checksumming may not
be all that informative if it introduces erroneous "bad" packets.

I will try to establish some performance figures in the next day or so on a
couple of SUN-3's. Naturally, I'll post the results....

		Jim

ARPA:	jim%cs.strath.ac.uk at ucl-cs.arpa, jim at cs.strath.ac.uk
UUCP:	jim at strath-cs.uucp, ...!seismo!mcvax!ukc!strath-cs!jim
JANET:	jim at uk.ac.strath.cs

"JANET domain ordering is swapped around so's there'd be some use for rev(1)!"



More information about the Comp.unix.wizards mailing list