Raid 1+0

[Jon Radel]

On 4/19/16 12:52 PM, Valeri Galtsev wrote:
> Correct, we didn't hear proof of one or another. I, however, can not think
> of any physical mechanism that can be involved which will lead in case of
> failure of one drive to failure of another. That is why I assume events
> are (pretty much) independent.
>
>
Personally I think you're thinking about it all wrong.  I didn't catch 
anyone claiming that failure of one drive caused the failure of another 
(though I've not slogged through the whole thread).  Only that failure 
of drives from the same manufacturing batch have a tendency to have 
similar lifespans, and therefore there is some correlation as to when 
they die.  They have the same design flaws. They have the same 
substandard components.   Etc., etc.    Why do you think that drives 
come with MTBF figures, and that they're not all the same for every 
drive?  That's the summary output of somebody's best estimation of the 
failure curve for that particular model.

Personally I've never had a clear cut example with disk drives, though I 
did own enough 750 mb drives from brand X some years ago to learn that 
the involved mechanism, on average, sucked compared to other brand X 
drives, and they were not to be trusted long term. However, I once saw 
this very clearly in LCD monitors where I had multiples of the same 
model.  Turns out that they were caught up in the big "counterfeit" 
capacitor scandal way back when, when due to imperfect industrial 
espionage, a manufacturer only thought they'd stolen the formula for a 
nice electrolyte.  Turns out there was one little factor they'd missed, 
the stabilizer that kept the capacitor from dropping dead at pretty much 
the same age as every other capacitor of that model.  There most 
certainly was correlation on those monitors failing.  Luckily they were 
all still in warranty. :-)

--Jon Radel
jon at radel.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3890 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20160419/f64fd313/attachment.bin>