On Thu, 23 Jun 2011 22:34:54 +0200, Stefan Sperling wrote:
On Thu, Jun 23, 2011 at 08:50:05AM +0200, martin wrote:
Hi all,
I've searched the list and could not find an answer to this.
I've run into the dreaded "Decompression of svndiff data failed"
problem.
Running http://www.szakmeister.net/fsfsverify/utility trying to fix
it I end up with a string of errors.
So far I've seen:
------------
- Error InvalidCompressedStream: Invalid compressed instr stream at
offset xxxx (Error -3 while decompressing: incorrect header check)
- Error InvalidCompressedStream: Invalid compressed data stream at
offset xxxx (Error -3 while decompressing: incorrect data check)
- Error InvalidWindow: The window header at offset xxx appears to be
corrupted
------------
We have so far never been able to pin down the cause of such
corruption problems. It could be a bug in Subversion (and you should
be upgrading to avoid the ones that are already known), but it might
just as well be a bug in some dependency Subversion is using (such as
APR),
or a bug in your operating system, or your disk controller or the
disk
itself having problems.
If you'd like to share your corrupt revision file (privately if you
like)
I'd be happy to take a look at it.
If you are lucky it's an instance of this problem:
http://subversion.tigris.org/issues/show_bug.cgi?id=3705
fsfsverify can fix some instances of this but not all.
I've fixed two such files manually so far which fsfsverify could not
fix.
And even if it's something else, maybe we can figure out what went
wrong.
And maybe if we see enough corrupt revision files we'll eventually be
able to pin it down to a bug in Subversion and fix it.
But the last time I was looking at a corrupted revision file it
simply
contained corrupted zip data. zlib could not decompress it anymore
and nobody knew why. The file was simply broken and we could not
reconstruct it within reasonable effort.
So keep backups :)
Thanks for all the feedback so far,
It's an old legacy system I inherited and the earlier guys only did a
hotcopy not verify, so on further investigation I found about 20 errors
in total in all it's history (fatal ones).
It's about half / half with the above error and else the checksum
error. The latter I can at least get to a stage where I can 'skip' it
and re-commit again.
For the former I'm stuck with fsfsverify just looping, and the error
revision had a zip file added to it just like yours.
I'll have a look into it and see if I can share the corrupt file.
Regarding hardware it's on a virtual server which hosts about 20 other
guests (and none of those have any data corruption), so I don't think
it's hw-related. It's not highly loaded nor are the VM host or any
guests.
It's running off CentOS and have about 66k revisions. I've tried to see
if I can find a pattern in it, and from the about 20 errors one certain
user is either the one comitting or the error occur when others merge in
his data. I have 2 out of 20 errors which does not follow this pattern.
Of course it could just be coincidence, but seems rather suspecious to
me. Also, this guy was absent from ~3000 forthgoing revisions and no
errors in the meantime, then he started comitting again and at exactly
the same time errors started to occur (not his own commit but when
someone merged his in later). He's using windows 7 but doesn't seem to
have any malware or the like on his system.
Also, there is no [seemingly] clear pattern about it having to be a
zip-file. Ordinary text-commits seem to trigger it as well, although the
majority is because of zip-files.
I'm mostly inclined to believe it's something network-related, but the
'evidence' I have point in another direction.
Again, I appreciate your time thinking about this,
/Martin
If I make any progress I'll be sure to let you guys know.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
