Re: CVS and NFS

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Steve,

There are many cases where NFS clients have opened a file on an NFS
server and written to it and the text written to disk is not the same
as the text the client was attempting to write.

Part of this is because the NFS protocols will not always be truthful
about the state of the write to the actual filesystem which may not be
100% complete at the time that the server tells the client that all is
well.

NFS typically uses UDP which does not necessarily have checksums enabled
and even if they are enabled they are fairly weak cksum32 which could
easily have multiple bits corrupted without detection.

For cases when NFS over TCP is being used, there have often been
interoperability problems between heterogeneous implementations of the
client server protocol and again, you only have a cksum32 checksum going
for you.

The ,v files in a CVS repository do not carry any individual or block
checksums, so it is entirely possible that the data written over the
network via NFS could be corrupted in many places along the path to
being written to disk and you may not find out for a long time that an
old revision is just not available to you any longer due to corruption of
part of the ,v file.

The CVS client/server interaction imposes additional checksums between
the CVS client machine and the CVS server machine, but those are lost
if there is a network layer between what the server considers a local
disk write and what the network considers an NFS write.

The concerns of the NFS protocol also exist for the Samba protocol.

While it may be that your particular installation has a good network
with no noise or back switches to corrupt packets along the way and a
completely homogeneous NFS implementation between your client and
server, it is still the case that the vast number of repository
corruptions reported appear to be strongly correlated to using NFS or
Samba for writes to the ,v file store.

Using local disk or local raid disk arrays or SAN attached filesystems
for the file store of the repository just do not have the same levels of
risk associated as using NFS or Samba.

As far as using NFS (or Samba) for your checked out trees, this is less
of a problem because a corruption there is much more likely to be
noticed as the revisions in your tree are all 'active' and it is fairly
easy to move a corrupt file aside and do a 'cvs update' to fix the
problem.

        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)

iD8DBQFF8uTFCg7APGsDnFERApTOAJ9EZEhd3VBECDOQsz214xQOBJHTMACgtHEX
IpoA5R2PLLnvNnzJBRDwzy8=
=Lp4v
-----END PGP SIGNATURE-----