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

Empty revisions causing repository failures

From: Christian Gils <cgils_at_lluvioso.org>
Date: Wed, 18 May 2011 09:33:24 -0400

Hello,

I've an interesting case of repository corruption about which I've not
been able to find any information.

I've version 1.5.6 using FSFS stored on ext3 (RHEL 5.4). The repository
contains about 39k revisions. Revisions 0-36672 are fine and dump
without any problems. Revisions 36673-8 fail to verify and give the
following error:

  svnadmin: Revision file lacks trailing newline

The same revisions fail to dump and give the following error:

  svnadmin: Can't read length line in file 'repo/db/revs/36/3667x

The failing revisions are on disk with varying, seemingly normal-looking
lengths:

  -rw-r--r-- 1 root apache 39104 May 13 17:50 repo/db/revs/36/36673
  -rw-r--r-- 1 root apache 28168 May 13 17:50 repo/db/revs/36/36674
  -rw-r--r-- 1 root apache 27831 May 13 17:50 repo/db/revs/36/36675
  -rw-r--r-- 1 root apache 18112 May 13 17:50 repo/db/revs/36/36676
  -rw-r--r-- 1 root apache 8983 May 13 17:50 repo/db/revs/36/36677
  -rw-r--r-- 1 root apache 28577 May 13 17:50 repo/db/revs/36/36678

When I inspect these files with a hex editor I find that they're full of
only zeros. That seems to explain why svn is choking on them. I suspect
that this occurred during an episode a couple of months ago when the
server's storage was yanked out from under it unexpectedly.
fsfsverify.py also chokes on these revisions when trying to seek within
them.

36679-HEAD seem to be fine as users have been committing and checking
out since then. A couple of days ago, however, local checkouts started
failing with the following error (the rev file listed is going to be one
of the failing revisions):

  svn: Can't read length line in file '/data3/tmp/repo/db/revs/36/3667x'

It looks like certain checkouts hit a file which prompts svn to try and
read those revisions and subsequently fail. As a result we have a
project which is unusable at the moment. Verification and dumping from
36679-HEAD will proceed until it hits a reference back to one of the
borked revisions and them terminate. I can't even dump both halves of
the repo and reimport omitting 36673-36678.

I'm kind of stuck as to how to fix this. Can I try to insert mocked-up
empty revisions in place of the zeroed ones so that svn can proceed with
dumping the more recent half of the repository or is there a better way
to do this?

Thanks in advance for any help anyone may be able to offer.

Christian

Received on 2011-05-18 15:34:01 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.