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