Re: Clarifications: CVS Import Bug - Please Respond

[Mark D. Baushke]

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

Derek Price <derek@ximbiot.com> writes:

> Bogdan,
> 
> The problem is that neither lock is working.  If CVS's directory-level
> locks were in place, you would see no problems at all. If only the RCS
> locks were in place, you might occassionally see change sets get
> overwritten, but you should see no file corruption.
> 
> As for why the RCS locks are not working with your NFS implementation, I
> cannot really tell you, except to say that NFS file locking is
> notoriously unreliable, which is why CVS uses its own style of directory
> level locks in the first place, and we generally recommend that CVS
> repositories not be stored on NFS servers.  IIRC, many of the problems
> stem from using non-homogenous sytems, e.g. a Solaris NFS Server and a
> Linux NFS client, or a NetApp accessed from a client it was not tested
> thoroughly with.  I do know of several companies out there that do store
> their CVS repositories on NFS servers without problems, but as I
> understand it, they are using high-end NetApps fully tested with their
> NFS clients.

Even in this case, you are asking for trouble unless you are still using
client/server access to focus transactions between the NetApp and a
single cvs server.

> 
> Other problems that have been reported stemming from non-homogenous NFS
> setups include random NUL bytes inserted in files on commit.  Don't know
> if there are others.

To be fair, most of the NUL bytes problems have been tracked down to not
having UDP checksums properly enabled throughout the network. There have
been occaions where the checked-out user trees on NFS have seen NUL
bytes for this reason as well.

Other NFS problems have included an excessive number of 'stale' CVS
locks when clients terminate and some odd race conditions with more than
one user trying to create write locks in the same directory at the same
time both believing they have obtained their exclusive lock.

Users that must use a SAN or NFS data store for the repository are urged
to use a client/server model with only one server acting on the data
store.

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

iD8DBQFC+4WYCg7APGsDnFERAp7mAJ4kIckQ1vvLELXw/N1ZzTzXofk8tQCdGdvk
euUWX+mmBm1l6a5tY9vldrQ=
=lqrk
-----END PGP SIGNATURE-----