info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Understanding problems with NFS & CVS.


From: Greg A. Woods
Subject: Re: Understanding problems with NFS & CVS.
Date: Wed, 5 Sep 2001 17:19:22 -0400 (EDT)

[ On Wednesday, September 5, 2001 at 10:18:09 (-0700), Paul Sander wrote: ]
> Subject: Re: Understanding problems with NFS & CVS.
>
> NFS is discouraged because there have traditionally been problems with
> subtle incompatibilities between implementations, and it must also be
> configured properly in order to maximize reliability.  Also, there have
> been numerous reports of file corruptions taking place while writing
> RCS archives over NFS, though I have not heard any lately on a properly
> configured system.

Depends on what you man by "properly configured".  SunOS-4.x was at
first considered to be "properly configured" even when UDP checksums
were disabled in the kernel!

> To properly configure NFS, you must hard-mount the volumes (not soft-mount).
> If there's an option to interrupt the NFS calls then enable that as well
> (otherwise your clients become unresponsive to signals when the NFS server
> hangs).

The bigger and harder to detect and understand problems are usually more
in the hardware end of things (though NFS file and record locking is
still black magic and Sun themselves will only vouch for it in the most
recent NFSv3 on the most recent versions of SunOS-5).

Even over TCP it's possible to get corruption, especially if your
packets traverse several different physical link layers.  All that
protects them at the transport layer is a 16-bit CRC.

Of course that's more or less all that protects SCSI too, but on a
parallel bus the error patterns detectable by a CRC check seem to work
more reliably.

Hopefully in any real server people have ECC memory buses, ECC DRAM, and
so on too....

As Wietse Venema, most recently famous as the author of Postfix, is fond
of saying, anyone experiencing file corruption is welcome to first prove
that it's not their hardware or networks causing it!  ;-)

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]