You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Marc Haisenko <ha...@webport.de> on 2004/05/14 11:23:01 UTC
Rescuing a repository
Hi folks,
we have a big repository (strings file is 3.1GB) on a RAID 5. Problem is, I
can't dump the repository, I always get a checksum mismatch in revision 336.
And it seems the latest revision has the same problem as well.
The system is a SuSE 8.2 with BDB 4.0.14, running SubVersion 0.37 (sic). I
yesterday and today tried to rescue the repository with with SubVersion 1.0.2
linked against BDB 4.1.25, and SubVersion 1.0.2 linked against BDB 4.2.52,
but everything failed.
First, I made a copy the repository so I can't mess up the original. I then
ran SVN 0.37/BDB 4.0.14 'svnadmin recover /export/rescue', which after
several minutes said "Input/output error" (note that despite the path this is
not a NFS directory). I then copied the copy to check whether there is a
problem with the RAID or something, but the copy went smooth. A fsck also
went without problems.
I then ran 'svnadmin dump /export/rescue', and everything went fine until it
reached revision 336 where a checksum mismatch was reported. Repeatedly
running the dump always yields the exact same checksum mismatch (always the
same checksums).
I suspected a defect RAM, installed Memtest86 and ran it but after letting it
run through the night no defective RAM was found.
Then today I downloaded BDB 4.1.25 and SVN 1.0.2, and compiled/linked SVN
1.0.2 against the BDB 4.1.25. Results are the very same as with SVN 0.37/BDB
4.0.14
I then also downloaded BDB 4.2.52, linked another SVN 1.0.2 against it an ran
its 'svnadmin recover'... this time the recover came back almost immediately,
reporting the correct current revision number (r506). But the dump still
doesn't work.
What's also interesting is that when trying to dump the revision 336 I get
different checksums for SVN 0.37 and SVN 1.0.2
SVN 0.37/BDB 4.0.14:
svn: Checksum mismatch on rep '4pi':
expected: fe339b5a4133f58051f1f15380f46413
actual: 4d21ea0c68cdde21698bc99e86eab179
SVN 1.0.2/BDB 4.1.25:
svn: Checksum mismatch on rep '4pi':
expected: fe339b5a4133f58051f1f15380f46413
actual: 7fc67fdbf244751f68f229270c97c3de
SVN 1.0.2/BDB 4.2.52:
svn: Checksum mismatch on rep '4pi':
expected: fe339b5a4133f58051f1f15380f46413
actual: 7fc67fdbf244751f68f229270c97c3de
I also tried experimenting with 'db_recover' but the 4.0.14 and 4.1.25
versions both yield the 'Input/output error'. And the 4.2.52 'db_recover'
returns immediately, no output whatsoever.
It's very important to get that repository up and running again as my boss is
fed up with SubVersion and will force me to ditch it if I can't get it
running again... the repository contains our main products.
So can anyone hint me what else I might try ? Or if nothing else works, how I
could possible try to fix that transaction by hand (I don't fear binary
editors ;-)
Thnx in advance,
Marc
--
Marc Haisenko
Systemspezialist
Webport IT-Services GmbH
mailto: haisenko@webport.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Rescuing a repository
Posted by kf...@collab.net.
Marc Haisenko <ha...@webport.de> writes:
> Okay, so what I've found is a bit weird:
> I suspected that the corrupt revision is caused by one or more of the three
> files that were added in that corrupt revision. And really looks like that,
> but isn't reproducable every time:
>
> I created a new repository and loaded the dump up to one revision before the
> corrupt one. I checked that repository out and added the files that my logs
> said were added in the corrup revision. I did a repository dump, everything
> went fine, then committed the three files (commit didn't give any error
> messages) and did another repository dump:
>
> svn: Checksum mismatch on rep '4ph':
> expected: eff6610598f05746eecd37c54f9ad706
> actual: 584136babe24324accc8b5bbb693dbdb
>
> Here we go again. I then tried to narrow it down to which file was causing the
> problem, so I recreated the repository as described above, checked it out and
> only added one of the three files. I did this for all three files and the
> dumps went fine.
>
> I was very surprised by that and tried the first test (which triggered the
> checksum mismatch) again, this time the dump went fine. So I can't reproduce
> this all the time :-(
>
> And to make matters worse, testing takes a long time as the repository is
> quite big, and I don't think I can send you the files which triggered the
> error (I have to talk to my boss, but he's out of town for a few days... I
> hope I don't forget asking him).
This is great investigation, though, thank you for taking the time...
Even though you couldn't reproduce it every time using the first
recipe above, were you able to reproduce it more than once?
Is there anything remarkable about the three files? Do they add up to
a lot of data, for example?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Rescuing a repository
Posted by kf...@collab.net.
Marc Haisenko <ha...@webport.de> writes:
> Okay, so what I've found is a bit weird:
> I suspected that the corrupt revision is caused by one or more of the three
> files that were added in that corrupt revision. And really looks like that,
> but isn't reproducable every time:
>
> I created a new repository and loaded the dump up to one revision before the
> corrupt one. I checked that repository out and added the files that my logs
> said were added in the corrup revision. I did a repository dump, everything
> went fine, then committed the three files (commit didn't give any error
> messages) and did another repository dump:
>
> svn: Checksum mismatch on rep '4ph':
> expected: eff6610598f05746eecd37c54f9ad706
> actual: 584136babe24324accc8b5bbb693dbdb
>
> Here we go again. I then tried to narrow it down to which file was causing the
> problem, so I recreated the repository as described above, checked it out and
> only added one of the three files. I did this for all three files and the
> dumps went fine.
>
> I was very surprised by that and tried the first test (which triggered the
> checksum mismatch) again, this time the dump went fine. So I can't reproduce
> this all the time :-(
>
> And to make matters worse, testing takes a long time as the repository is
> quite big, and I don't think I can send you the files which triggered the
> error (I have to talk to my boss, but he's out of town for a few days... I
> hope I don't forget asking him).
This is great investigation, though, thank you for taking the time...
Even though you couldn't reproduce it every time using the first
recipe above, were you able to reproduce it more than once?
Is there anything remarkable about the three files? Do they add up to
a lot of data, for example?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Rescuing a repository
Posted by Marc Haisenko <ha...@webport.de>.
On Monday 17 May 2004 17:03, kfogel@collab.net wrote:
> Marc Haisenko <ha...@webport.de> writes:
> > I do have one suspect, but I'd like to verify that one for sure,
> > I'll tell you tomorrow whether I was right or not ;-)
>
> Thanks -- will watch for the post.
Okay, so what I've found is a bit weird:
I suspected that the corrupt revision is caused by one or more of the three
files that were added in that corrupt revision. And really looks like that,
but isn't reproducable every time:
I created a new repository and loaded the dump up to one revision before the
corrupt one. I checked that repository out and added the files that my logs
said were added in the corrup revision. I did a repository dump, everything
went fine, then committed the three files (commit didn't give any error
messages) and did another repository dump:
svn: Checksum mismatch on rep '4ph':
expected: eff6610598f05746eecd37c54f9ad706
actual: 584136babe24324accc8b5bbb693dbdb
Here we go again. I then tried to narrow it down to which file was causing the
problem, so I recreated the repository as described above, checked it out and
only added one of the three files. I did this for all three files and the
dumps went fine.
I was very surprised by that and tried the first test (which triggered the
checksum mismatch) again, this time the dump went fine. So I can't reproduce
this all the time :-(
And to make matters worse, testing takes a long time as the repository is
quite big, and I don't think I can send you the files which triggered the
error (I have to talk to my boss, but he's out of town for a few days... I
hope I don't forget asking him).
C'ya,
Marc
--
Marc Haisenko
Systemspezialist
Webport IT-Services GmbH
mailto: haisenko@webport.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Rescuing a repository
Posted by Marc Haisenko <ha...@webport.de>.
On Monday 17 May 2004 17:03, kfogel@collab.net wrote:
> Marc Haisenko <ha...@webport.de> writes:
> > I do have one suspect, but I'd like to verify that one for sure,
> > I'll tell you tomorrow whether I was right or not ;-)
>
> Thanks -- will watch for the post.
Okay, so what I've found is a bit weird:
I suspected that the corrupt revision is caused by one or more of the three
files that were added in that corrupt revision. And really looks like that,
but isn't reproducable every time:
I created a new repository and loaded the dump up to one revision before the
corrupt one. I checked that repository out and added the files that my logs
said were added in the corrup revision. I did a repository dump, everything
went fine, then committed the three files (commit didn't give any error
messages) and did another repository dump:
svn: Checksum mismatch on rep '4ph':
expected: eff6610598f05746eecd37c54f9ad706
actual: 584136babe24324accc8b5bbb693dbdb
Here we go again. I then tried to narrow it down to which file was causing the
problem, so I recreated the repository as described above, checked it out and
only added one of the three files. I did this for all three files and the
dumps went fine.
I was very surprised by that and tried the first test (which triggered the
checksum mismatch) again, this time the dump went fine. So I can't reproduce
this all the time :-(
And to make matters worse, testing takes a long time as the repository is
quite big, and I don't think I can send you the files which triggered the
error (I have to talk to my boss, but he's out of town for a few days... I
hope I don't forget asking him).
C'ya,
Marc
--
Marc Haisenko
Systemspezialist
Webport IT-Services GmbH
mailto: haisenko@webport.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Rescuing a repository
Posted by kf...@collab.net.
Marc Haisenko <ha...@webport.de> writes:
> I do have one suspect, but I'd like to verify that one for sure,
> I'll tell you tomorrow whether I was right or not ;-)
Thanks -- will watch for the post.
> Oh, and by the way: we're using SubVersion for thirteen or fourteen months
> now... can't life without it now :-)
Hope your boss agrees :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Rescuing a repository
Posted by kf...@collab.net.
Marc Haisenko <ha...@webport.de> writes:
> I do have one suspect, but I'd like to verify that one for sure,
> I'll tell you tomorrow whether I was right or not ;-)
Thanks -- will watch for the post.
> Oh, and by the way: we're using SubVersion for thirteen or fourteen months
> now... can't life without it now :-)
Hope your boss agrees :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Rescuing a repository
Posted by Marc Haisenko <ha...@webport.de>.
On Monday 17 May 2004 16:22, kfogel@collab.net wrote:
> Did you ever find out the cause of the corruption, though?
>
> The words "data corruption" make us very nervous. When it turns out
> to be bad RAM, we breathe a sigh of relief (though it would still be
> nice if Subversion had some way to be more graceful about handling
> such situations!).
>
> However, if it wasn't bad RAM, the possibility exists that it was
> Subversion itself...
>
> Any new information?
>
> -Karl
No, I haven't found the cause... and it's embarrasing for me, but the corrupt
repository was in life use for many, many months (I guess about seven or
eight). I did ask on the list about how to fix the problem but didn't get a
helpful response back then. And since checkouts and commits were working
correctly we kept on using that repository (only dumps didn't work). But now
I was getting very nervous and so asked again ;-)
I do have one suspect, but I'd like to verify that one for sure, I'll tell you
tomorrow whether I was right or not ;-)
Oh, and by the way: we're using SubVersion for thirteen or fourteen months
now... can't life without it now :-)
C'ya,
Marc
--
Marc Haisenko
Systemspezialist
Webport IT-Services GmbH
mailto: haisenko@webport.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Rescuing a repository
Posted by Marc Haisenko <ha...@webport.de>.
On Monday 17 May 2004 16:22, kfogel@collab.net wrote:
> Did you ever find out the cause of the corruption, though?
>
> The words "data corruption" make us very nervous. When it turns out
> to be bad RAM, we breathe a sigh of relief (though it would still be
> nice if Subversion had some way to be more graceful about handling
> such situations!).
>
> However, if it wasn't bad RAM, the possibility exists that it was
> Subversion itself...
>
> Any new information?
>
> -Karl
No, I haven't found the cause... and it's embarrasing for me, but the corrupt
repository was in life use for many, many months (I guess about seven or
eight). I did ask on the list about how to fix the problem but didn't get a
helpful response back then. And since checkouts and commits were working
correctly we kept on using that repository (only dumps didn't work). But now
I was getting very nervous and so asked again ;-)
I do have one suspect, but I'd like to verify that one for sure, I'll tell you
tomorrow whether I was right or not ;-)
Oh, and by the way: we're using SubVersion for thirteen or fourteen months
now... can't life without it now :-)
C'ya,
Marc
--
Marc Haisenko
Systemspezialist
Webport IT-Services GmbH
mailto: haisenko@webport.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Rescuing a repository
Posted by kf...@collab.net.
Marc Haisenko <ha...@webport.de> writes:
> Well, I finally managed to rescue my repository, thank you all for you
> help !
>
> What I did was a normal dump up to the corrupt revision, an
> incremental dump just after the corrup revision, create a new
> repository, load the first dump, check out the repository, add the
> files from the corrupt revision (luckily I have a commit hook that
> sends e-mails to me and luckily I have all of them) and then load the
> incremental dump.
>
> I guess this only worked so well because the files that were added in
> the corrupt revision were never changed afterwards... one of them was
> deleted in a later revision, but this was no problem.
Did you ever find out the cause of the corruption, though?
The words "data corruption" make us very nervous. When it turns out
to be bad RAM, we breathe a sigh of relief (though it would still be
nice if Subversion had some way to be more graceful about handling
such situations!).
However, if it wasn't bad RAM, the possibility exists that it was
Subversion itself...
Any new information?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Rescuing a repository
Posted by kf...@collab.net.
Marc Haisenko <ha...@webport.de> writes:
> Well, I finally managed to rescue my repository, thank you all for you
> help !
>
> What I did was a normal dump up to the corrupt revision, an
> incremental dump just after the corrup revision, create a new
> repository, load the first dump, check out the repository, add the
> files from the corrupt revision (luckily I have a commit hook that
> sends e-mails to me and luckily I have all of them) and then load the
> incremental dump.
>
> I guess this only worked so well because the files that were added in
> the corrupt revision were never changed afterwards... one of them was
> deleted in a later revision, but this was no problem.
Did you ever find out the cause of the corruption, though?
The words "data corruption" make us very nervous. When it turns out
to be bad RAM, we breathe a sigh of relief (though it would still be
nice if Subversion had some way to be more graceful about handling
such situations!).
However, if it wasn't bad RAM, the possibility exists that it was
Subversion itself...
Any new information?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Rescuing a repository
Posted by Marc Haisenko <ha...@webport.de>.
On Monday 17 May 2004 15:51, Tobias Ringström wrote:
> Marc Haisenko wrote:
> > Well, I finally managed to rescue my repository, thank you all for you
> > help !
> >
> > What I did was a normal dump up to the corrupt revision, an incremental
> > dump just after the corrup revision, create a new repository, load the
> > first dump, check out the repository, add the files from the corrupt
> > revision (luckily I have a commit hook that sends e-mails to me and
> > luckily I have all of them) and then load the incremental dump.
>
> It's good to hear that it worked. I hate to state the obvious, but I
> really really hope that you've also implemented a backup strategy by
> now, especially since your near-disaster was likely caused by a hardware
> problem.
>
> /Tobias
Well, if a daily CPIO snapshot of the repository qualifies as "backup" we have
one ;-)=) (the snapshot is saved on a different machine)
Now that the repository is working again we can finally backup dumps instead
of CPIO snapshots...
--
Marc Haisenko
Systemspezialist
Webport IT-Services GmbH
mailto: haisenko@webport.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Rescuing a repository
Posted by Tobias Ringström <to...@ringstrom.mine.nu>.
Marc Haisenko wrote:
> Well, I finally managed to rescue my repository, thank you all for you help !
>
> What I did was a normal dump up to the corrupt revision, an incremental dump
> just after the corrup revision, create a new repository, load the first dump,
> check out the repository, add the files from the corrupt revision (luckily I
> have a commit hook that sends e-mails to me and luckily I have all of them)
> and then load the incremental dump.
It's good to hear that it worked. I hate to state the obvious, but I
really really hope that you've also implemented a backup strategy by
now, especially since your near-disaster was likely caused by a hardware
problem.
/Tobias
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Rescuing a repository
Posted by Marc Haisenko <ha...@webport.de>.
Well, I finally managed to rescue my repository, thank you all for you help !
What I did was a normal dump up to the corrupt revision, an incremental dump
just after the corrup revision, create a new repository, load the first dump,
check out the repository, add the files from the corrupt revision (luckily I
have a commit hook that sends e-mails to me and luckily I have all of them)
and then load the incremental dump.
I guess this only worked so well because the files that were added in the
corrupt revision were never changed afterwards... one of them was deleted in
a later revision, but this was no problem.
C'ya,
Marc
--
Marc Haisenko
Systemspezialist
Webport IT-Services GmbH
mailto: haisenko@webport.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Rescuing a repository
Posted by Marc Haisenko <ha...@webport.de>.
Well, I finally managed to rescue my repository, thank you all for you help !
What I did was a normal dump up to the corrupt revision, an incremental dump
just after the corrup revision, create a new repository, load the first dump,
check out the repository, add the files from the corrupt revision (luckily I
have a commit hook that sends e-mails to me and luckily I have all of them)
and then load the incremental dump.
I guess this only worked so well because the files that were added in the
corrupt revision were never changed afterwards... one of them was deleted in
a later revision, but this was no problem.
C'ya,
Marc
--
Marc Haisenko
Systemspezialist
Webport IT-Services GmbH
mailto: haisenko@webport.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Rescuing a repository
Posted by Marc Haisenko <ha...@webport.de>.
On Friday 14 May 2004 17:03, Max Bowsher wrote:
> Marc, before you try hunting through bdb files for the checksum, try:
>
> db_dump -kp db/representations > reps.dump
> your-favourite-editor reps.dump
>
> The file should contain lots of lines like this:
> .....
> 36
> ((fulltext 1 5 (md5 16 `\f4~\d3\fc\b5\0b\b9Q\aa\c2\af\9e\86Zc)) 2 3g)
> 37
> ((delta 0 (md5 16 \e0\a8\b1"\ac\e2\ab\1d\a1\a2\c6}\deE\19\a0)) (1 0
> ((svndiff 1 0 n7) 2 20 d3))) .....
>
> Search for the pair of lines:
> 4pi
> ((.....some data.....)
>
> (Where 4pi is the representation from your error message)
> Now, edit the md5sum to \00 repeated 16 times, and save the file
>
> mv db/representations db/representations.old
> db_load db/representations < reps.dump
>
> You should now be able to dump the repository, but be aware that part of
> the problem revision will be corrupt.
>
> Max.
Woah ! That didn't work at all ! :-) First, the dumped reps.dump is 1.2MB
while the representations file is 1.8MB... then the reloaded representations
file is just 247kB ! And svnadmin dump then says "svn: No such representation
'4p9'"
db_load also had an error message at the very beginning:
db_load: Lock table is out of available locks
db_load: Lock table is out of available locks
db_load: Cannot allocate memory
but then continued happily... and left a mess, it seems :-)
I'll now the try the binary editor method ;-)
--
Marc Haisenko
Systemspezialist
Webport IT-Services GmbH
mailto: haisenko@webport.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Rescuing a repository
Posted by Max Bowsher <ma...@ukf.net>.
Marc Haisenko wrote:
> On Friday 14 May 2004 15:15, Edmund Horner wrote:
>> Edmund Horner wrote:
>>
>> PS. I just ran through the process on one of my own repositories (one
>> which wasn't working out anyway... I'm not always as reckless as I sound
>>
>> :-) and it seems to go ok.
>>
>> BUT I forgot to mention: make a backup first! The file containing the
>> checkums is db/representations. Not sure if you need to backup other
>> files if you're simply going to modify 32 innocuous data bytes.
>
> When experimenting with sensible data I normally do even two backups... better
> to be over-careful here ^_^
>
>> In my case the checksum occurred twice in the file. Not sure if that's
>> always the case. The checksum is stored as 16 binary bytes (not as 32
>> hex digits).
>>
>> When this happened to me, the advice was to dump the file using the BDB
>> dump utility, edit it there, and then recreate the file. That didn't
>> work for me so I used a hex editor.
>
> This helps a lot, thanks... luckily I have an excellent binary editor (biew)
> at hand :-) I'll try this...
Marc, before you try hunting through bdb files for the checksum, try:
db_dump -kp db/representations > reps.dump
your-favourite-editor reps.dump
The file should contain lots of lines like this:
.....
36
((fulltext 1 5 (md5 16 `\f4~\d3\fc\b5\0b\b9Q\aa\c2\af\9e\86Zc)) 2 3g)
37
((delta 0 (md5 16 \e0\a8\b1"\ac\e2\ab\1d\a1\a2\c6}\deE\19\a0)) (1 0 ((svndiff 1 0 n7) 2 20 d3)))
.....
Search for the pair of lines:
4pi
((.....some data.....)
(Where 4pi is the representation from your error message)
Now, edit the md5sum to \00 repeated 16 times, and save the file
mv db/representations db/representations.old
db_load db/representations < reps.dump
You should now be able to dump the repository, but be aware that part of the problem revision will be corrupt.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Rescuing a repository
Posted by Marc Haisenko <ha...@webport.de>.
On Friday 14 May 2004 15:15, Edmund Horner wrote:
> Edmund Horner wrote:
>
> PS. I just ran through the process on one of my own repositories (one
> which wasn't working out anyway... I'm not always as reckless as I sound
>
> :-) and it seems to go ok.
>
> BUT I forgot to mention: make a backup first! The file containing the
> checkums is db/representations. Not sure if you need to backup other
> files if you're simply going to modify 32 innocuous data bytes.
When experimenting with sensible data I normally do even two backups... better
to be over-careful here ^_^
> In my case the checksum occurred twice in the file. Not sure if that's
> always the case. The checksum is stored as 16 binary bytes (not as 32
> hex digits).
>
> When this happened to me, the advice was to dump the file using the BDB
> dump utility, edit it there, and then recreate the file. That didn't
> work for me so I used a hex editor.
This helps a lot, thanks... luckily I have an excellent binary editor (biew)
at hand :-) I'll try this...
C'ya,
Marc
--
Marc Haisenko
Systemspezialist
Webport IT-Services GmbH
mailto: haisenko@webport.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Rescuing a repository
Posted by Edmund Horner <ch...@chrysophylax.cjb.net>.
Edmund Horner wrote:
PS. I just ran through the process on one of my own repositories (one
which wasn't working out anyway... I'm not always as reckless as I sound
:-) and it seems to go ok.
BUT I forgot to mention: make a backup first! The file containing the
checkums is db/representations. Not sure if you need to backup other
files if you're simply going to modify 32 innocuous data bytes.
In my case the checksum occurred twice in the file. Not sure if that's
always the case. The checksum is stored as 16 binary bytes (not as 32
hex digits).
When this happened to me, the advice was to dump the file using the BDB
dump utility, edit it there, and then recreate the file. That didn't
work for me so I used a hex editor.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Rescuing a repository
Posted by Edmund Horner <ch...@chrysophylax.cjb.net>.
Edmund Horner wrote:
PS. I just ran through the process on one of my own repositories (one
which wasn't working out anyway... I'm not always as reckless as I sound
:-) and it seems to go ok.
BUT I forgot to mention: make a backup first! The file containing the
checkums is db/representations. Not sure if you need to backup other
files if you're simply going to modify 32 innocuous data bytes.
In my case the checksum occurred twice in the file. Not sure if that's
always the case. The checksum is stored as 16 binary bytes (not as 32
hex digits).
When this happened to me, the advice was to dump the file using the BDB
dump utility, edit it there, and then recreate the file. That didn't
work for me so I used a hex editor.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Rescuing a repository
Posted by Edmund Horner <ch...@chrysophylax.cjb.net>.
Marc Haisenko wrote:
> Thanks for the infos... if I lose a node, how much information is lost ? E.g.
> is a node a complete transaction or just part of a transaction ? How does it
> affect the data to come ?
Sorry not mention that the first time: a node is generally one version
of one file. So other files in that revision will be ok, and other
versions of that file (subject to deltafication dependencies) will be ok.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Rescuing a repository
Posted by Marc Haisenko <ha...@webport.de>.
On Friday 14 May 2004 15:04, Edmund Horner wrote:
> Marc Haisenko wrote:
> > ...
> >
> > I then ran 'svnadmin dump /export/rescue', and everything went fine until
> > it reached revision 336 where a checksum mismatch was reported.
> > Repeatedly running the dump always yields the exact same checksum
> > mismatch (always the same checksums).
> >
> > I suspected a defect RAM, installed Memtest86 and ran it but after
> > letting it run through the night no defective RAM was found.
> >
> > ...
>
> Hi Marc, I've been in exactly the same situation (well, apart from not
> worrying about a boss and it being a much smaller repository). In my
> case the cause was defective RAM (which, btw, I'm still using ;-).
>
> --> The first thing to do is figure out which node is causing the
> checksum error. This can usually be done by looking in the dump output
> for the last node header mentioned. If the Text-Content-Length is
> smaller than the bytes output after that header (after the PROPS-END
> line), then that node is giving the MD5 error).
>
> When this happened to me the dev@ people suggested I edit nodes to set
> the checksum for that node to 0000....... as this checksum matches any
> data. You'll probably lose that node, of course, but at least you'll be
> able to dump all the remaining nodes.
>
> (If you get the same problem later on in the dump -- perhaps there's
> another node that has a diff against the corrupt one; perhaps there's
> another corrupt node -- repeat from the line marked -->).
>
> You might want to ask "how do I edit the checksum?" to which someone
> other than I can probably give a more helpful answer. :-)
>
> Hope this helps,
>
> Edmund.
Thanks for the infos... if I lose a node, how much information is lost ? E.g.
is a node a complete transaction or just part of a transaction ? How does it
affect the data to come ?
C'ya,
Marc
--
Marc Haisenko
Systemspezialist
Webport IT-Services GmbH
mailto: haisenko@webport.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Rescuing a repository
Posted by Edmund Horner <ch...@chrysophylax.cjb.net>.
Marc Haisenko wrote:
> ...
> I then ran 'svnadmin dump /export/rescue', and everything went fine until it
> reached revision 336 where a checksum mismatch was reported. Repeatedly
> running the dump always yields the exact same checksum mismatch (always the
> same checksums).
>
> I suspected a defect RAM, installed Memtest86 and ran it but after letting it
> run through the night no defective RAM was found.
> ...
Hi Marc, I've been in exactly the same situation (well, apart from not
worrying about a boss and it being a much smaller repository). In my
case the cause was defective RAM (which, btw, I'm still using ;-).
--> The first thing to do is figure out which node is causing the
checksum error. This can usually be done by looking in the dump output
for the last node header mentioned. If the Text-Content-Length is
smaller than the bytes output after that header (after the PROPS-END
line), then that node is giving the MD5 error).
When this happened to me the dev@ people suggested I edit nodes to set
the checksum for that node to 0000....... as this checksum matches any
data. You'll probably lose that node, of course, but at least you'll be
able to dump all the remaining nodes.
(If you get the same problem later on in the dump -- perhaps there's
another node that has a diff against the corrupt one; perhaps there's
another corrupt node -- repeat from the line marked -->).
You might want to ask "how do I edit the checksum?" to which someone
other than I can probably give a more helpful answer. :-)
Hope this helps,
Edmund.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org