[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cvs repository files being corrupted
From: |
Todd Denniston |
Subject: |
Re: cvs repository files being corrupted |
Date: |
Mon, 13 Feb 2006 18:09:31 -0500 |
User-agent: |
Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) |
Please keep the replies on list as others may be able to use the info to
either help you or figure their problem out from the archives.
Thanks.
Jeremy Birch wrote:
Todd,
Q1) is your repository on an nfs or smb share (or other network
filsystem)?
no - it is local to the server
Q2) what access method are you using, i.e., :ext:, :pserver:, :local:,
or direct to drive?
:pserver:
Q3) which distribution version of Linux are you using?
SuSe 9.1
This reminded me of some problems seen back in 2001:
http://lists.gnu.org/archive/html/info-cvs/2001-01/msg00003.html
http://lists.gnu.org/archive/html/info-cvs/2001-01/msg00016.html
http://lists.gnu.org/archive/html/info-cvs/2001-05/msg00202.html
I think validate_repo.pl is something you may want to use as well, it
searches for faults with the ,v files IIRC.
http://cvs.savannah.nongnu.org/viewcvs/ccvs/contrib/validate_repo.pl?rev=1.1&root=cvs&view=log
some of these bugs seem similar expect our is ALWAYS just after the
"desc @@" in the file, no matter which file it is. It tends to happen
more on big binary files so we suspect it has something to do with how
long that file is being worked on (ie higher probability of a clash with
some other process) but have no confirmation of this.
We are working in client-server mode, no one is using NFS mounts or
other such mechanisms to access the repository.
Good!!
BTW which client mode, it may make a difference in later debugging.
It seems to happen most often on tags (but of course that tickles a lot
of files) but we have seen it on individual ascii file commits too
Any ideas and suggestions gratefully accepted
1) What kind of access to the physical hard drive is your server using?
IDE/SCSI/iSCSI/NFS
(if the server is accessing the repository over NFS it can cause these faults,
it is not necessarily a client thing.
2) How old is the drive/cpu/memory on the computer?
it might be time to do a good (well as good as is possible with already
faulting parts) backup, and run badblocks (with full write testing, which is
why you HAVE TO HAVE THE BACKUP) and memtest86 on the system.
3) this might be a really long shot, and I would not expect it of a modern
linux system, but you might try turning off the memmap option in the compile.
[search bug-cvs for where I had to do it to an old sun machine, to see how.].
if the other things show no problems and the memmap change does "fix" the
problem please let us know.
Cheers
Jeremy
--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter