Bill Davidsen (davidsen@xxxxxxx) wrote on 21 March 2008 19:01:
>Peter Rabbitson wrote:
>> I was actually specifically advocating that md must _not_ do anything
*************************
>> on its own. Just provide the hooks to get information (what is the
**********
>> current stripe state) and update information (the described repair
>> extension). The logic that you are describing can live only in an
>> external app, it has no place in-kernel.
>
>So you advocate the current code being in the kernel, which absent a
>hardware error makes blind assumptions about which data is valid and
>which is not and in all cases hides the problem, instead of the code I
>proposed, which in some cases will be able to avoid action which is
>provably wrong and never be less likely to do the wrong thing than the
>current code?
The current code doesn't do anything on its own, it must be invoked by
the user, which is an important difference.
I agree that blindingly setting parity is not good; that's an argument
for removing it from the kernel, not adding something :-)
Why is it there? This is for Neil to answer; I merely conjecture that
it was already there. For example, it's necessary after a raid5 array
is created, because it's done creating an n-1 degraded array and
adding the last disk afterwards. It's also done when an array is
dirty. This is a situation where it's done without asking the user but
it seems to me that in this case that's the right action: if the
parity doesn't agree with the data it's either because the parity was
not yet updated at the moment of the unclean shutdown or because it
was updated but not the data itself. In both cases the parity should
reflect the current data situation.
The /sys/..../syn_action is just an interface added much later to
trigger the code. The check action is useful but I think repair is too
risky. I doubt it should be available.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
