You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Scott Harger <sc...@pinpointinsight.com> on 2005/10/26 19:04:37 UTC
checksum problem
We recently converted from CVS to Subversion and are having intermittent problems with our repository. We'd appreciate any suggestions help us resolve them.
We run Subversion 1.1.4 on Red Hat and have Red Hat and Windows clients. We use the apache module to access the repository over https.
Initially we used cvs2svn to load a bdb backed repository. At various times we are unable to check out certain directories in the repository. After waiting a while (or perhaps a reboot) we can then check out the same directory fine. Also, while we are in this state "svnadmin dump" fails with the following type of error message:
svn: Checksum mismatch while reading representation:
expected: 69123b311ffba600abadb4e08478e8fd
actual: 038044a1bd093f747958fad16b99807a
I have noticed that while in this state if I download certain files through the web browser interface (they are typically 10-20M zip files) they appear to be truncated and do not match the same file from a directory that was previously checked out successfully.
While in this state I can dump early versions of the repository (say < revision 500) but for revisions after that I am unable to and get the checksum errors. Again, after a reboot or some undetermined time period this behavior can go away and I can checkout and dump without issue and the files accessed through the web interface are correct.
When we can't checkout a directory our svn error log frequently has messages like this:
[Sun Oct 23 22:42:24 2005] [error] [client 10.1.1.31] Provider encountered an error while streaming a REPORT response. [500, #0]
[Sun Oct 23 22:42:24 2005] [error] [client 10.1.1.31] A failure occurred while driving the update report editor [500, #160004]
[Sun Oct 23 22:42:24 2005] [error] [client 10.1.1.31] Checksum mismatch on rep '2a46':! expected: 2ee6c00158c39537f8db1c5bf771d4ec! actual: 45a9d3f50b5fd1d0397fd1b2a199c308! [500, #160004]
Also we've seen things like this a couple times:
[Thu Oct 13 02:04:23 2005] [error] [client 10.1.1.31] Reference to non-existent node 'dg3.0.tx' in filesystem '/svn/dev/db' [500, #160014]
I have run svnadmin recover after seeing these kinds of messages, and that has helped some. But it doesn't seem to do anything for the intermittent checksum errors.
To eliminate bdb as a cause of our problems, we created a fsfs backed repository and loaded it with a dump of the latest revision from the bdb repository (a dump created during one of those times that it could run successfully without the checksum errors)
Sadly we are still seeing the weird behavior with the fsfs backed repository in that we cannot check out certain directories at certain times. From the error log:
[Wed Oct 26 11:00:10 2005] [error] [client 10.1.1.37] Provider encountered an error while streaming a REPORT response. [500, #0]
[Wed Oct 26 11:00:10 2005] [error] [client 10.1.1.37] A failure occurred while driving the update report editor [500, #160004]
[Wed Oct 26 11:00:10 2005] [error] [client 10.1.1.37] Checksum mismatch while reading representation:! expected: 229bd9f706e9c459074504e381e9b749! actual: 5ef38f74f814a76f6fc7c66c66800c45! [500, #160004]
Thanks,
Scott
Re: checksum problem
Posted by Scott Harger <sc...@pinpointinsight.com>.
Thanks for the suggestion Paul.
I was able to verify that the md5sum values change for a repository revision
file when the
repository is showing the checksum errors. So it indeed looks to be a
hardware / system
problem.
Scott
----- Original Message -----
From: "Paul Koning" <pk...@equallogic.com>
To: <sc...@pinpointinsight.com>
Cc: <us...@subversion.tigris.org>
Sent: Wednesday, October 26, 2005 3:57 PM
Subject: Re: checksum problem
>>>>>> "Scott" == Scott Harger <sc...@pinpointinsight.com> writes:
>
> Scott> We recently converted from CVS to Subversion and are having
> Scott> intermittent problems with our repository. We'd appreciate any
> Scott> suggestions help us resolve them. ...
>
> Scott> To eliminate bdb as a cause of our problems, we created a fsfs
> Scott> backed repository and loaded it with a dump of the latest
> Scott> revision from the bdb repository (a dump created during one of
> Scott> those times that it could run successfully without the
> Scott> checksum errors)
>
> Scott> Sadly we are still seeing the weird behavior with the fsfs
> Scott> backed repository in that we cannot check out certain
> Scott> directories at certain times. ...
>
> My guess is a data integrity problem on your system -- disks, bus,
> memory, ...
>
> You could do md5sum on the repository files (the internal guts of the
> repository) while it is having the problem, and again when it seems to
> magically correct itself. I'd expect a mismatch somewhere.
>
> paul
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: checksum problem
Posted by Paul Koning <pk...@equallogic.com>.
>>>>> "Scott" == Scott Harger <sc...@pinpointinsight.com> writes:
Scott> We recently converted from CVS to Subversion and are having
Scott> intermittent problems with our repository. We'd appreciate any
Scott> suggestions help us resolve them. ...
Scott> To eliminate bdb as a cause of our problems, we created a fsfs
Scott> backed repository and loaded it with a dump of the latest
Scott> revision from the bdb repository (a dump created during one of
Scott> those times that it could run successfully without the
Scott> checksum errors)
Scott> Sadly we are still seeing the weird behavior with the fsfs
Scott> backed repository in that we cannot check out certain
Scott> directories at certain times. ...
My guess is a data integrity problem on your system -- disks, bus,
memory, ...
You could do md5sum on the repository files (the internal guts of the
repository) while it is having the problem, and again when it seems to
magically correct itself. I'd expect a mismatch somewhere.
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org