Re: Redundancy check using "echo check > sync_action": error reporting?

[Bill Davidsen <davidsen@tmr.com>]

Carlos Carvalho wrote:
> Bill Davidsen (davidsen@tmr.com) 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.
>
>   
Difference from what? Is issuing the 'repair' action on its own? How 
would adding code which lets that repair have a higher chance of success 
be bad? Sector consistency errors don't show up during normal operation, 
there's no hardware error, just bad data. It only shows up during 
'check' or 'repair,' so the recovery would never be triggered without 
express user request.

> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>   


-- 
Bill Davidsen <davidsen@tmr.com>
  "Woe unto the statesman who makes war without a reason that will still
  be valid when the war is over..." Otto von Bismark