On Wed, Nov 10, 2010 at 08:55:49PM -0500, Edward Ned Harvey wrote:
> > From: Stefan Sperling [mailto:stsp_at_elego.de]
> >
> > > It's 100% consistent. I get the same checksum error, on the same file,
> > every time. I have a supposed "good" copy of the slave repo, at rev
> 4050...
> > which will fail every time at 4061 (or something like that)... The only
> > explanation I can find is a md5sum collision going undetected, and then
> some
> > larger operation has an md5sum which fails as a result. I know it's
> > astronomically impossible, but I can't come up with any other explanation.
> >
> > So you can reproduce it reliably? That's very interesting.
> > I'd like to try to debug this. If it's possible to arrange access to your
> repository
> > data please contact me off-list. Thanks.
>
> I believe we found the cause for mine. It was hardware error, which was
> introduced silently into rev 4390 of my repo. But I can't speak for the
> other folks here... If they're having bugs, they might have bugs.
>
> One quick question though: If the system is calculating checksums,
> shouldn't it store the checksums for future reference? I find it very
> surprising that I can run "svnadmin verify" and no errors are detected, yet
> svnsync dies with a md5sum mismatch. Maybe the md5sums are only used
> transiently and only by svnsync?
By design, the handling of checksums is sane.
Checksums are stored in the repository, and are calculated by the
repository layer. A client can only tell the repository what it expects
the checksum to be. When the client sends content, the repository
calculates the content's checksum and compares that to the expected
checksum. See also http://svn.haxx.se/dev/archive-2010-07/0426.shtml,
where Mike Pilato explains this in detail. [That thread is about a commit
I made that added property content checksums to dump files. The commit was
later reverted because it's just as cheap to compare the actual property
contents since we treat property content as strings (but the loader
doesn't do that, yet).]
I'm not sure what svnadmin verify is doing wrong in your case.
But I know that there are corruptions it doesn't detect, and we're
planning to improve this situation:
http://subversion.tigris.org/issues/show_bug.cgi?id=3706
Received on 2010-11-11 13:29:55 CET