[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

filesystem crash, FSFS corrupted (svn 1.3.2)

From: Andreas Hasenack <andreas_at_conectiva.com.br>
Date: 2007-04-10 22:11:28 CEST

We had a filesystem crash and after running fsck, the svn backend (FSFS)
was corrupted. Some checkouts work, most don't.

svnadmin recover says everything is fine, but svnadmin verify quickly
finds errors in very old revisions.

svnadmin dump also doesn't work, stopping on the first error it

So far, we are running this script which seems to skip over the bad

svnadmin dump --incremental -r $r /svn | svnadmin load $(pwd)/repos/

$r is looped over all revisions

Right now, I'm not that much worried about the lost data. What worries
me is that lost data is preventing me from getting to the good data. I
thought svnadmin recover would do that: nuke the corrupted parts and
leave me with the good ones, but that is not the case.

The above procedure (dump & reload) is still running, should take a few

The error messages are various. Here are some:
# svnadmin verify /svn
* Verified revision 14.
svnadmin: Can't read file '/svn/db/revs/99182': End of file

- malformed header

It also seems fsck moved some files from revprops to revs. For example,
that 99182 one from the error above:
# cat /svn/db/revs/99182
K 10
V 8
K 8
V 27
K 7
V 12
Tagging 0.03

This looks like it should belong to revprops, but I'm not that familiar
with FSFS internals. Anyway, seems everything was badly corrupted.

So, basically, is there some magic command that would fix the
consistency of the repository, leaving me with just the data that can be
salvaged? Is the dump&reload procedure I'm doing above the best thing
(besides after having a sane backup, of course)?

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Apr 10 22:12:02 2007

This is an archived mail posted to the Subversion Users mailing list.