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. FSFS does not have tools
to bring it back to a consistent state, which even the worst case
scenario of fsck can do. 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
Received on Fri Jun 29 00:10:23 2007