Xref: utzoo comp.protocols.nfs:627 comp.protocols.tcp-ip:9677
Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!snorkelwacker!paperboy!osf!meissner
From: meissner@osf.osf.org (Michael Meissner)
Newsgroups: comp.protocols.nfs,comp.protocols.tcp-ip
Subject: Re: Which gives best data integrity:  NFS, UUCP, or FTP?
Message-ID: <2182@paperboy.OSF.ORG>
Date: 20 Dec 89 21:19:13 GMT
References: <1972@dover.sps.mot.com>
Sender: news@OSF.ORG
Reply-To: meissner@osf.org (Michael Meissner)
Distribution: na
Organization: Open Software Foundation
Lines: 56

In article <1972@dover.sps.mot.com> cowan@spanky.sps.mot.com () writes:
|
|Any one got a few minutes to answer a few questions?  
|
|For UUCP, FTP, and NFS, in what way (if any) do each of these programs
|perform data integrity checks and data correction?  I'm not talking
|about how a packet reaches the destination, but how, if by sheer magic
|a bit in the data being transferred is munged up, it is detected and
|corrected.  At what levels (in the protocol stack) is the data
|integrity checking done.

When I was at Data General, I had some particularly bad experiences
with NFS.  Our ethernet(s) at the time had a variety of hardware
hooked up to it (Data General MV's running AOS/VS communicating with
X.25 and some TCP/IP over ethernet, MV's running DG/UX communicating
with TCP/IP, MSDOS-based PC's speaking X.25, etc.).  We added some Sun
workstations to bootstrap to the AViiON (88k based) system.  The Sun's
were running 3.5 SunOS.  We started noticing random file corruption
problems when compiling stuff on the Sun's on NFS mounted partitions
from MV's running DG/UX.

At first we thought it was some bug in our server code, but the
network people tracked it down to random packets getting a bit or two
trashed.  In order to get higher throughput, SunOS 3.5 NFS uses UDP
connections.  Unlike TCP, UPD connections can come out of order,
dupiclated, trashed, etc. and it is assumed that higher layers of
software will deal with this.  However there is an option to enable
the checksums on UDP packets, and not deliver the packets that had a
bad checksum specified.

The way we dealt with the problem was to take the NFS reference source
from Sun, recompile the one module that spit out the UDP packets to
turn on UDP checksums, ar the module into the appropriate kernel
library, and regen the systems.  Viola, it fixed our problem.

By the way, we did attempt to report the bug to Sun, and where told it
was a feature, since checksumming slows down the machine.  In
practice, we never noticed the slowdown, and we could go back to
building the software, without some object file randoming having it's
bits changed.

|What I'm really interested in is knowing is: Which one of these three
|methods is most reliable (in a data integrity sense) for transferring
|data, and why?   (Opinions, without sensible backing arguments, will
|be directed to /dev/null.)
|
|Any takers?

See above.  The normal NFS over UDP depends on your link layers of the
software not to trash the bits.  Both FTP (via the reliable TCP
streams), and UUCP (via the low level packet handler) are protected by
checksums or the like.  How well those checksums behave under stress,
(ie, whether they can fixup multiple bit errors or not) I don't know.
I have heard about random FTP corruption problems, but most of those
are either not using binary/image mode, or ftp'ing a file from a NFS
mounted disk.