On 29-Jun-07, at 9:40 AM, Andreas Hasenack wrote:
> On Fri, Jun 29, 2007 at 09:26:57AM -0300, Toby Thain wrote:
>>> FSFS does not have tools
>>> to bring it back to a consistent state, which even the worst case
>>> scenario of fsck can do.
>>
>> But what was the root cause of the corruption? Since you are not
>> talking
>> about a hardware fault, you must be talking about a software fault.
>
> Why does it matter?
IMHO it is relevant to the question of budgeting effort for a
recovery tool or scavenger.
Because if you are talking about recovering from software faults,
then you have to bring the release methodology of the project into
the argument, such as: test coverage; regression testing; release
criteria; details of repository storage design (fault resilience,
this is also relevant to hw faults); built-in runtime consistency
checks... and so on. Depending on the rigour of all those project
aspects, it's possible to make some fairly confident statements about
the likelihood of software-caused corruption - especially as a stable
release ages.
Back to the question... It may be that svndump simply needs an option
to turn on a scavenging mode where it is much more tolerant of
inconsistency (--tryharder).
> Let's say the backups were whosed too. The poor
> admin will have nothing left, *nothing*, sort of rm -rf the repo and
> restart from scratch. In that scenario, saying "svn+fsfs has no
> recovery
> tool, you are doomed indeed" seems worse than "I tried the recovery
> procedures and was able to get back 30% of the data".
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jun 29 15:39:46 2007