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

Re: FSFS Issue...

From: Malcolm Rowe <malcolm-svn-dev_at_farside.org.uk>
Date: 2005-12-07 22:04:07 CET

On Mon, Dec 05, 2005 at 06:10:17AM -0500, John Szakmeister wrote:
> On Sunday 04 December 2005 11:23, Malcolm Rowe wrote:
> [snip long interesting explanation]

s/explanation/hypothesis/. While I think it's a pretty good one (it
fits the results exactly), I haven't yet got any evidence to back it up.

> I don't know either. It's really bizarre. I am going to see if I can apply
> the same logic to the other corrupted revisions that I have and see if it
> lines up. I too am dumb-founded as to why we would attempt to rewrite the
> delta instead of aborting the transaction. Looking through the backend code,
> I don't see any place where we would attempt such a thing. :-/

Right, and I can't _replicate_ such a thing either. I've tried injecting
read and write errors into various places during the commit phase,
and all I get back is something like:

svn: Commit failed (details follow):
svn: Can't read file '/home/malcolm/fault-inject/repo2/db/revs/1': Input/output error

and the transaction is deleted.

> Well, I've got a clean version of the corrupted repository, and so far have
> been unable to recreate the original corruption. The only thing I haven't
> done yet is to use mod_dav_svn to do the commit. I need to set up Apache
> locally (I usually just use the davautocheck when developing Subversion).

It occurred to me that it is possible that mod_dav_svn is a necessary
part of the reproduction. Though if that is the case, I'm not going to
be able to replicate it, because I don't have Apache installed.

What I think I might do is see if it's possible to create a 'broken'
(ra_local) client that I can persuade to corrupt the repository, then
look at how we can fix the problem in libsvn_fs_fs - we shouldn't really
be depending upon the caller to do the right thing.

> On the flipside, I now have an algorithm for recovering the bad files.

Yes, a partial result, at least.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 7 22:10:50 2005

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

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