Karl Fogel wrote:
> blair_at_tigris.org writes:
>> This feature is not in 1.4, it's new code in 1.5.
>>
>> I do think it should be pulled since it may leave a false impression
>> that you have a good repository.
>
> [I've moved discussion from the issue tracker to the mailing list.]
>
> Blair is talking about having 'svnadmin recover' work on FSFS
> repositories. Background: I recently applied Jeremy Whitlock's patch
> for issue #2992, which made FSFS recovery do better error checking.
>
> But Blair argues above, and in more detail in the issue, that we
> should not have a recovery feature for FSFS repositories at all.
>
> I (tentatively) think we should. The final three things an FSFS
> commit does are, in order:
>
> - write the 'revs/FOO' file (atomically)
> - write the 'revprops/FOO' file (atomically)
> - write the 'current' file (atomically)
>
> If recovery sees both 'revs/FOO' and 'revprops/FOO', it can recreate
> 'current'. Given that the vast majority of non-svn-aware backup
> programs will work by just copying everything in no particular order,
> then it will sometimes happen that a repository will be missing
> everything but 'current'. In that case, we can recover and should;
> and if we're missing more than just 'current', recovery should fail,
> (which is what Jeremy's patch for issue #2992 ensures).
I think most backup programs work in alphabetical order. Take tar, you'll back
up current and then descend into revs and then revprops. So in this case,
recover should check that current has the corresponding revs/FOO and
revprops/FOO files and if it doesn't back down current.
The only time where 'svnadmin recover' will do anything with useful consistency
is if the commit process crashes before it moves current into place. The
'svnadmin recover' was added for DBD because DBD supports a recover option to
handle database crashes and using 'svnadmin dump'.
> So with that patch applied, I think FSFS recovery is both useful (for
> the race-condition case) and safe (in other cases, recovery will fail,
> which is what we want).
>
> One could argue that merely offering the feature creates a "moral
> hazard" -- that admins will think any old backup tool is fine, because
> the repository can always be recovered. But they won't think that for
> very long, once they discover that not everything can recovered from,
> and we can help that by documenting it. It seems to me that if we
> have an easy way to fix one particular kind of repository breakage, we
> should offer it.
The type of breakage this code is handling is very rare. When is svn going to
crash between moving revprops/FOO into place and moving current into place?
Regards,
Blair
--
Blair Zajac, Ph.D.
CTO, OrcaWare Technologies
<blair_at_orcaware.com>
Subversion training, consulting and support
http://www.orcaware.com/svn/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-04 17:36:05 CET