Clarifications: Stale CVS Locks

[Oproescu Bogdan (KTXA 3)]

   Hello Mark, 

   Thanks for your message below. We've encountered these stale CVS locks 
   in the past quite frequently on our CVS Central Server, and we are 
   used to regularly cleaning these CVS Locks as a result. If the situation 
   gets very messy for many Modules and Repositories, we can delete all these 
   involved CVS Lock Files, and then we have our own script to regenerate them 
   all back again ( repository list traversal ) in only a few seconds.  

   Cheers, Bogdan 

   Bogdan Oproescu   

   CREDIT SUISSE FINANCIAL SERVICES
   Technology & Services
   Advanced Middleware &
   Development Environments KTXA 3 
   Postfach 600
   CH-8070 Zürich
   Tel.: +41 1 334 6846
   Fax.:+41 1 332 8024
   E-Mail: bogdan.oproescu@credit-suisse.ch
   Internet: http://www.credit-suisse.ch/de/index.html

-----Original Message-----
From: mdb@juniper.net [mailto:mdb@juniper.net] On Behalf Of Mark D. Baushke
Sent: Thursday, August 11, 2005 7:07 PM
To: Derek Price
Cc: Oproescu Bogdan (KTXA 3); 'bug-cvs@nongnu.org'; 'Bernd Jendrissek'; Larry 
Jones
Subject: Re: Clarifications: CVS Import Bug - Please Respond 

-----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-----