FSFS Corruption and missing Rev files

[Daniel Jurado <ju...@gmail.com>]

Hi all.

Since my first approach to SVN i'd never had to migrate my repository
but now I'm guess really in trouble.

Everything works fine here, committing, checking out and any other
regular activity but, when I tried for the first time to dump the rep
(fsfs, svn, 1.4.2 (r22196)) i got this annoying message (annoying
because I'm on rev 963 right now):

"svnadmin: No such revision 761"

Taking a closer look to my db tree I could see that the 761 file is
missing on db\revs, but not just it. 762, 796, 801 and some other
ones.

Running a classic svnadmin verify I got the same 'No such revision 761'.

Trying now a svnadmin recover, I got a 'successful recover' message,
showing that 963 is my last revision.

When I try do dump parts of the repo, got an error on every range
bigger than the first missing file. Like this:

svnadmin dump -r 0:760 "Repo path"
...
OK

svnadmin dump -r 763:770 "Repo path"
svnadmin: Reference to non-existent node '1q.0.r762/4787' in
filesystem 'Repo path'

svnadmin dump -r 810:900 "Repo path"
svnadmin: Reference to non-existent node '5b.0.r801/6696' in
filesystem 'Repo path'

I can export the code inside the repo normally (that's how I
"migrated" it to its new home) but, of course, I lost every comment,
revision history, tracks, etc.

Can someone tell me if i missed something here?

PS: One interesting point here is that those missing revs was probably
committed through a network share. BUT, as I am using fsfs, I should
not fear this, though. Am I correct?

-- 
Daniel Jurado
+55 11 93907180
mail/voip : jurado **at** gmail **dot** com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: FSFS Corruption and missing Rev files

[Malcolm Rowe <ma...@farside.org.uk>]

On Tue, Nov 28, 2006 at 01:10:28AM -0200, Daniel Jurado wrote:
> "svnadmin: No such revision 761"
> 
> Taking a closer look to my db tree I could see that the 761 file is
> missing on db\revs, but not just it. 762, 796, 801 and some other
> ones.
> 

"Uh oh".

> Can someone tell me if i missed something here?
> 

No, you've not missed anything - if those files are gone, you have a
problem (and it'll be a bigger one once you hit a revision that wants to
use one of those missing revisions as a delta base).

Conceivably, it might be possible (but pretty hard) to piece together a
working filesystem by recreating those revisions as empty commits (that
touch the right files with a no-change delta), but at best you'd have
lost all the versions of the files whose delta path travels through one
of those revisions.  Your best bet by far is to restore the missing
files from a backup.

Is there any chance that something else could have interfered with the
revision files?  A virus scanner?  A user, perhaps (if you're using a
file:/// URL)?  The only reason I ask is that I've not heard of random
revision files being deleted before.

> PS: One interesting point here is that those missing revs was probably
> committed through a network share. BUT, as I am using fsfs, I should
> not fear this, though. Am I correct?
> 

That's right.  In this area, FSFS depends only on POSIX-style (fcntl)
locks to serialise concurrent access to the filesystem, and atomic
renames to move the new revision files into place.  As far as I was
aware, that's all the common network filesystems in use save NFSv2
(which I'm pretty sure doesn't support locking).

We also re-open and fsync() the new revision file after writing (and, on
Linux clients, the containing directory as well) to ensure that the file
is correctly written to disk, so you'd have to have a pretty odd error
for the network filesystem to report the file as written and then later
as missing.

If I had to guess a cause I'd guess either something interfered with the
db/ directory, or you had/have a problem with your on-disk filesystem,
and fsck or similar has removed the revision files.

Regards,
Malcolm