On 29-Jun-07, at 10:44 AM, Andreas Hasenack wrote:
> On Fri, Jun 29, 2007 at 10:39:19AM -0300, Toby Thain wrote:
>>
>> 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,
>
> So, either way, you would say that such a recovery tool is not needed,
> because:
> - if it's a hardware fault, nothing you can do about it
> - if it's a software bug, the project shouldn't have released the
> software in that state
No, it's more subtle than that. I'm not sure the list needs to hear
my rationale again, since the issue is so hypothetical.
But in a nutshell, IMHO:
- hw and sw causes must be treated separately;
- hw causes are boring; if you care about your data you'll be using
prophylactics such as good admin practices and/or ZFS;
- sw causes strongly invoke all the engineering questions I raised
earlier, and until you have examined and answered all those and
others, you cannot know whether a scavenger is justified. The effort
may be much better spent in proactive defenses such as test coverage,
regression tests, runtime consistency checks, preventive design,
prudent release engineering, etc.
If you don't feel this clarifies my position then I'll have to leave
it at that. :)
--Toby
>
> ---------------------------------------------------------------------
> 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 16:59:22 2007