On 28-Jun-07, at 7:10 PM, Andreas Hasenack wrote:
> On Thu, Jun 28, 2007 at 06:51:30PM -0300, Toby Thain wrote:
>>
>> On 28-Jun-07, at 5:02 PM, Andreas Hasenack wrote:
>>
>>> On Thu, Jun 28, 2007 at 01:57:16PM -0300, Toby Thain wrote:
>>>>> I have used BDB with very large repositories (~50Gb) and it
>>>>> survived
>>>>> many
>>>>> hardware failures (after running recovery and with proper log
>>>>> files
>>>>> archived). Now I'm also using FSFS, and had to spend about a week
>>>>> manually recovering from corruptions (caused by hardware failure).
>>>>
>>>> Prevention is better than cure... People really should start
>>>> looking more
>>>
>>> Is this the reason why there is no recovery for FSFS?
>>
>> It's not clear how much effort to "cure" hardware-caused problems is
>
> That's not what I meant/asked.
>
>> worthwhile, especially when a solution is available at a lower
>> layer. Any
>> discussion of this topic has to begin with asking, "where are the
>> errors
>> coming from." You mentioned hardware failure. There are two
>> surefire ways
>> of dealing with it: 1) ZFS 2) backups. A scavenging tool that is
>> supposed
>> to cope with arbitrary corruption (i.e. hardware problem) should
>> be a last
>> resort, IMHO? And this scenario is pretty much guaranteed to
>> result in
>> -some- loss. Hence, "Prevention is better than cure".
>
> You seem to imply tools like fsck are useless.
In the case of ZFS, nearly so, yes. In fact fsck does not exist there.
> 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.
--Toby
> Even worse, a corruption at revision 1 out of
> 150.000 will make svnadmin dump fail, even when the subsequent commits
> did not depend on that one in particular (i.e., no delta).
>
>
> ---------------------------------------------------------------------
> 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 14:33:08 2007