Hello Neil ,
On Thu, 17 Feb 2011, NeilBrown wrote:
On Wed, 16 Feb 2011 20:14:50 -0500 Phil Turmel <philip@xxxxxxxxxx> wrote:
On 02/16/2011 07:52 PM, NeilBrown wrote:
So when you do the computation on all of the bytes in all of the blocks you
get a block full of answers.
If the answers are all the same - that tells you something fairly strong.
If they are a "all different" then that is also a fairly strong statement.
But what if most are the same, but a few are different? How do you interpret
that?
Actually, I was thinking about that. (You suckered me into reading that PDF
some weeks ago.) I would be inclined to allow the kernel to make corrections
where "all the same" covers individual sectors, per the sector size reported
by the underlying device.
To see what I am strongly against having the kernel make automatic
corrections like this, see
http://neil.brown.name/blog/20100211050355
Paraphrasing from the above , Mind all I did was skim the article .
But this statement from your conclusions leaves me a tad lost .
"... It could even be done entirely in user-space by suspending IO to the
affected stripe (md already supports that), making the required update, then
resuming IO. ..."
Hopefully the quantity of 'required update'ng would be extremely small .
Tho if not , Then we'll start seeing locked at user level reports . Of
course the process should be completely kill'able & nice'able in userspace as
long as there is documantation available to our 'informed admin' on howto limit
the processes possible abuses to his primary runtime service(s) . Which will
probably be file sharing to other servers or workstations .
I am quite sure you have thought thru that particular (and many other)
scenarios before making that proposal . Would you please either here OR at the
original document above inform us a little more on how you feel you'd like to
approach the problem of a 'large update' ? if a 'large update' should even be
possible not even sure of can or not .
I also find myself agreeing with your 'to conclude the conclusion'-)
that automaticity should in 'general' be avoided . An Aware & informed admin
is the best method to be used .
And finally BUT not the least , Thank you . Even tho we have our
differences of opinions on other aspects of the MD structure .
Tia , JimL
--
+------------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network&System Engineer | 3237 Holden Road | Give me Linux |
| babydr@xxxxxxxxxxxxxxxx | Fairbanks, AK. 99709 | only on AXP |
+------------------------------------------------------------------+
--
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
