Re: mismatch_cnt again

[Piergiorgio Sartor <piergiorgio.sartor@nexgo.de>]

Well...

> Is this an offer to submit a patch ?? :-)

almost, I was looking into RAID-6 for this, but unfortunately
it seems I'll need external manpower too... :-)

> I disagree.  You do need a model.  The particular features of the
> model would be the weight and wind-resistance of the person so that
> you can estimate what extra wind resistance is needed to reduce terminal
> velocity such that the impact will be something that the person's
> legs can absorb.  So you also need the model to describe the legs
> in enough detail so that a suitable target terminal velocity can
> be determined.

Well, sorry, but IMHO this is needed only when you design
the parachute, not when you jump out of the plane.

It seems that here some people, including me, would have
found useful such a feature.
For example I've a RAID-10 which shows a mismatch_cnt of
256, but everything seems to work fine.
The disks are new, no SMART errors or else.
Where the mismatch belong I do not know.
What should I do? Try to fill up the MD device and then
see if the mismatch is still there?
It would be much better to know which file, if any, is
affected and then take the proper countermeasures.

At the moment, since everything runs fine, I do not dare
to start a resync, since it will not be better than
leaving the things like they're right now.
I'm in the hope that some file creation or similar will fix
the mismatch.
Or do you have a better option?

> If we proactively hand out parachutes that can just barely land a
> small dog safely, then we aren't doing any people any favours,
> and probably are making their situation less safe because they are
> more likely to take a risk in the belief that their parachute
> will protect them - which it might not.

Do not over stretch the example.
The parachute, in the MD case, will not remove any risk,
it will simply help people to manage a damage, that might
occure for any reasons, including SW bugs, better.

I mean, will you swear that the actual RAID software will
never cause, by its own, a mismatch between disks?
I guess not.
So, why not to give a mechanism to enable user to look
further into mismatches and be able to take a proper action?

> Certainly manpower is an issue - and it is pointless spending it
> on something that you think sounds nice, but have no evidence that it
> will actually address a real need.

It seems some people, here, have this need.
So, it is real.

I see not only myself asking for such features like returning
the block address of the mismatch count or trigger a *proper*
repair instead of a random one.

Frankly speaking, the whole resync/repair concept is, at the
moment, a waste of manpower (when it was done), since repairing
or not a RAID does not change the underlayining situation.
It just sets the mismatch_cnt to zero, but if an error is
present there are good chances it will still be there.
And this is the problem: after the resync people will *feel*
secure, people *feel* safe (because there is a "repair"),
but in the end the risk is simply increased (as per your
example about dog-parachute).

Again, manpower is always an issue and priorities are needed,
of course, but what if we vote, here, for such a feauture and
then it turns out it is "most wanted"?

Written that, since complaining alone does not help, how to
proceed in the case I would like to print the MD block address
of a mismatch? Which source code file would be more sensible
to look into?

Thanks for you attention and sorry for the rant,

P.S.: I like very much the MD thing, that's the reason
why I would like to see it improved.

bye,

-- 

piergiorgio