On Sat, May 14, 2011 at 10:58:12AM +0200, Steinar Bang wrote:
> Platform:
> debian 6.0.1 "squeeze",
> subversion 1.6.16dfsg-1+b1,
> fsfsverify.py from http://svn.apache.org/repos/asf/subversion/trunk/contrib/server-side
> python 2.6.6-3+squeeze6
>
> (information about the repository at the end of this mesage)
>
> Yesterday I discovered that my subversion repository is broken. Trying
> to do "svnadmin dump" breaks at revision 683:
> sb_at_somehost:/tmp/svnrepo$ svnadmin dump /tmp/svnrepo/svn/ >/dev/null
> * Dumped revision 0.
> * Dumped revision 1.
> ...
> * Dumped revision 681.
> * Dumped revision 682.
> svnadmin: Decompression of svndiff data failed
>
>
> I found some threads on this list of people with the same error message
> suggesting to use fsfsverify.py. I assumed that the trunk version from
> the repository would be the newest and most stable so that's the version
> I've tried.
>
> I've done all of my experiments with fsfsverify.py, and one attempt at
> using fsfsfixer, on a copy of the repository, created with the command:
> (cd /tmp/svnrepo; rm -rf svn; cp -a /usr/local/svn/ .)
>
>
> The first run of fsfverify.py /tmp/svnrepo/svn/db/revs/0/683 reports the
> following:
> ...
> NodeRev Id: 4-683.0.r683/12232
> type: file
> text: DELTA 683 1910 890 1548 30aadd70339eb7b41ab6eb20a6220202
> prop: PLAIN 683 12138 81 0 685faf6a4230ea531a31a12e4b3cb565
> cpath: /trunk/someprog/metamodeller/Makefile.msvc
> copyroot: 0 /
> <Svndiff so: 1916 ver: 1>
>
> Error InvalidCompressedStream: Invalid compressed data stream at offset 2247 (Error -3 while decompressing: incorrect data check, <Window wo:1920 so:0 sl:0 tl:1548 cil: 317 cdl: 561 il:315 dl:729 whl:8 wl:886>)
>
> Try running with -f to fix the revision
>
>
> When I run fsfsverify.py -f /tmp/svnrepo/svn/db/revs/0/683 I see:
> ...
> NodeRev Id: 4-683.0.r683/12232
> type: file
> text: DELTA 683 1910 890 1548 30aadd70339eb7b41ab6eb20a6220202
> prop: PLAIN 683 12138 81 0 685faf6a4230ea531a31a12e4b3cb565
> cpath: /trunk/someprog/metamodeller/Makefile.msvc
> copyroot: 0 /
> <Svndiff so: 1916 ver: 1>
> Copy 893 bytes from offset 1920
> Write 893 bytes at offset 1916
> Fixed? :-) Re-run fsfsverify without the -f option
>
>
> Which looks good. However, fsfverify.py /tmp/svnrepo/svn/db/revs/0/683
> reports:
The script probably took a wrong guess.
Hopefully this is the known corruption problem with a duplicate block of
data in the revision file.
Can you check if the original revision file (i.e. not modified by
fsfsverify.py) somewhere contains a data block which contains data
that matches the data around byte offset 1916?
Usually the spot where the corruption appears (offset 1916 in your case)
contains an incomplete representation, but the representation data in the
duplicated block is good.
One of way of locating the duplicate block is to open the file in a hex
editor and search the entire file for hex strings that occur around or
after 1916. Try to locate boundaries of representations, which look as
follows:
https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_fs/structure
A representation begins with a line containing either "PLAIN\n" or
"DELTA\n" or "DELTA <rev> <offset> <length>\n", where <rev>, <offset>,
and <length> give the location of the delta base of the representation
and the amount of data it contains (not counting the header or
trailer). If no base location is given for a delta, the base is the
empty stream. After the initial line comes raw svndiff data, followed
by a cosmetic trailer "ENDREP\n".
So if you find a duplicated block of data you should be able to fix this
problem by copying representation data from the duplicate block to the
corrupted location. DO NOT change any byte offsets in the file while doing
this. If you cannot squeeze the data in because it would overlap with
subsequent data you're out of luck but I've never seen this happen.
Usually there is enough room to fit the data, but you might have to add
padding. Any dummy byte will do, I usually use 0x42.
Another possibility is that offset 2247 is wrong. In this case the
expected svndiff data is probably located elsewhere and the offset
in the representation header should be adjusted.
This is of course not an easy task and it is unfortunate that people
keep running into this problem. The source of the problem is not yet
known :( If you have any further questions just ask. If you cannot
get it fixed at all but can share the revision file privately I will
have a go at it.
Good luck!
Received on 2011-05-14 12:11:55 CEST