Re: CVS and heavily loaded systems

[Derek R. Price]

Hi Peter,


Peter Toft wrote:
> In the release of CVS 1.12.13 (Oct. 3 2005) it was noted that
> "[http://www.kb.cert.org/vuls/id/680620 #680620] for more info),
> several issues involving potential data-loss on heavily loaded
> systems, some minor potential crashes, hangs, and several minor
> annoyances in CVS client and server behavior."
>
> Can anyone tell more on this? I have recently found severe problems


I believe I was referring to these NEWS items (from the NEWS file) in
that release announcement.  The notes in parentheses are new annotations:

* Thanks to Rahul Bhargava <address@hidden>, heavily loaded systems
  suffering from a disk crash or power failure will not lose data they
  claimed to have committed.

  (CVS used to print its commit success messages prior to syncing to
   disk.)

* CVS now does correct locking during import.

  (`cvs import' wasn't creating any locks!  Imports were apparently rare
   enough that it took a long time for anyone to notice and report
   this.)


This fix may also be seen as avoiding data loss on heavily loaded
server, but it is less critical since it only affected the history and
val-tags files:

* CVS now locks the history and val-tags files before writing to them.
  Especially with large repositories, users should no longer see new
  warnings about corrupt history records when using the `cvs history'
  command.  Existing corrupt history records will still need to be
  removed manually.  val-tags corruption should have had less obvious
  effects, but removing the CVSROOT/val-tags file and allowing a 1.11.21
  or later version of CVS to regenerate it may eliminate a few odd
  behaviors and possibly cause a slight speed up of read transactions in
  large repositories over time.


There is also this enhancement, which fixes a long standing CVS
deficiency, but only lost data if the user didn't notice the conflict
message and subsequently deleted the .#* file created by CVS in their
sandbox:

* CVS now remembers that binary file merge conflicts occurred until the
  timestamp of the updated binary file changes.


There is also this fix, which only applies to the (hopefully rare) case
of Windows clients accessing a *local* repository *concurrently with
older clients*, but which could cause data loss:

* The Windows client now creates locks compatible with older versions of
  CVS by default.  This should only be relevant if your client is
  accessing a local repository concurrently with another, older client.
  If you would like to disable compatibility mode (because it is
  slightly faster), edit the LOCK_COMPATIBILITY flag in
  windows-NT/config.h and recompile.


For more information on any of these issues, you may refer to the
ChangeLogs, the address@hidden email archives, and the CVS
repository itself.


> with CVS 1.12.9 - which very well can originate from clients having a
> very high CPU load committing huge files through an SSH pipe towards
> the CVSROOT on a remote machine where the network is not the fastest
> one.  I have seen checksum errors and locking problems with CVS 1.12.9
> from time to time.


I am not aware of any current problems in the 1.12.9 code which might
cause checksum errors.  CVS watches its network pipes and should be
waiting to write data when their buffers are full.  If it is not, then
please report it as a bug.

Your locking issues may have been a symptom of the import problem.  I
know of no other problems.  This problem existed in both 1.11.x and 1.12.x.

You may like to know that there is a problem with 1.12.13 clients
communicating with older servers.  We've fixed it in 1.11.22 and the
1.12.x trunk, but it is waiting for the 1.12.14 release, which will
hopefully be in the next week or two.

Cheers,

Derek
-- 
Derek R. Price
CVS Solutions Architect
Get CVS support at Ximbiot <http://ximbiot.com>!
v: +1 248.835.1260
f: +1 248.835.1263
<mailto:address@hidden>