The remaining drive would only have been flagged as dodgy if the bad
sectors had been found, hence my comments (and general best practice)
about data scrub's being necessary. While I agree it's possibly likely
that the enterprise drive would flag errors earlier, I wouldn't
necessarily bet on it. Just because a given sector has successfully been
read a number of times before doesn't guarantee that it will be read
successfully again, and again the enterprise drive doesn't try as hard.
In the absence of scrubs, resilvering can be the hardest thing the drive
does, and by my experience is likely to show up errors that haven't
occurred before. But you make a good point about retrying the resilver
until it works, presuming I don't hit a "too many errors, device
faulted" condition. :-)
I would have liked to go RaidZ2, but performance has dictated mirroring.
Physical, Financial and Capacity constraints have conspired together to
restrict me to 2 way mirroring rather than 3 way, which would have been
my next choice. :-)
Regards
Tristan
(Who is now going to spend the afternoon figuring out how to win lottery
by osmosis: http://en.wikipedia.org/wiki/Osmosis :-) )
________________________________
From: Tim Cook [mailto:t...@cook.ms]
Sent: Wednesday, 26 August 2009 3:01 PM
To: Tristan Ball
Cc: thomas; zfs-discuss@opensolaris.org
Subject: Re: [zfs-discuss] Using consumer drives in a zraid2
On Tue, Aug 25, 2009 at 11:38 PM, Tristan Ball
<tristan.b...@leica-microsystems.com> wrote:
Not upset as such :-)
What I'm worried about that time period where the pool is resilvering to
the hot spare. For example: one half of a mirror has failed completely,
and the mirror is being rebuilt onto the spare - if I get a read error
from the remaining half of the mirror, then I've lost data. If the RE
drives return's an error for a request that a consumer drive would have
(eventually) returned, then in this specific case I would have been
better off with the consumer drive.
That said, my initial ZFS systems are built with consumer drives, not
Raid Edition's, as much as anything as we got burned by some early RE
drives in some of our existing raid boxes here, so I had a general low
opinion of them. However, having done a little more reading about the
error recovery time stuff, I will also be putting in RE drives for the
production systems, and moving the consumer drives to the DR systems.
My logic is pretty straight forward:
Complete disk failures are comparatively rare, while media or transient
errors are far more common. As a media I/O or transient error on the
drive can affect the performance of the entire pool, I'm best of with
the RE drives to mitigate that. The risk of a double disk failure as
described above is partially mitigated by regular scrubs. The impact of
a double disk failure is mitigated by send/recv'ing to another box, and
catastrophic and human failures are partially mitigated by backing the
whole lot up to tape. :-)
Regards
Tristan.
The part you're missing is the "good drive" should have flagged bad
long, long before a consumer drive would have. That being the case, the
odds are far, far less likely you'd get a "bad read" from an enterprise
drive, than you would get a "good read" from a consumer drive constantly
retrying. That's ignoring the fact you could re-issue the resilver
repeatedly until you got the response you wanted from the "good drive".
In any case, unless performance is absolutely forcing you to do
otherwise, if you're that paranoid just do a raid-z2/3, and you won't
have to worry about it. The odds of 4 drives not returning valid data
are so rare (even among RE drives), you might as well stop working and
live in a hole (as your odds are better being hit by a meteor or winning
the lottery by osmosis).
I KIIID.
--Tim
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
