On Fri, Jan 22, 2010 at 04:12:48PM -0500, Miles Nordin wrote: > w> http://www.csc.liv.ac.uk/~greg/projects/erc/ > > dead link?
Works for me - this is someone who's written patches for smartctl to set this feature; these are standardised/documented commands, no reverse engineering of DOS tools required. > IMHO it is just a sucker premium because the feature is worthless > anyway. There are two points here: - is the feature worth paying the premium for "raid edition" drives, assuming it's the main difference between them? If there are other differences, they have to factor into the assessment. For me and others here, the answer is clearly "no". - for two otherwise comparable drives, for comparable price, would I choose the one with this feature? That's a very different question, and for me and others here, the answer is clearly "yes". > From the discussion I've read here, the feature is designed > to keep drives which are *reporting failures* to still be considered > *GOOD*, and to not drop out of RAIDsets in RAID-on-a-card > implementations with RAID-level timeouts <60seconds. No. It is designed to make drives report errors at all, and within predictable time limits, rather than going non-responsive for indeterminate times and possibly reporting an error eventually. The rest of the response process, whether from a raid card or zfs+driver stack, and whether based on timeouts or error reports, is a separate issue. (more on which, below) Consider that a drive that goes totally failed and unresponsive can only be removed by timeout; this lets you tell the difference between failure modes, and know what's a sensible timeout to consider the drive really-failed. > The solaris timeout, because of m * n * o multiplicative layered > speculative retry nonsense, is 60 seconds or 180 seconds or many > hours, so solaris is IMHO quite broken in this regard but also does > not benefit from the TLER workaround: the long-TLER drives will not > drop out of RAIDsets on ZFS even if they report an error now and then. There's enough truth in here to make an interesting rant, as always with Miles. I did enjoy it, because I do share the frustration. However, the key point is that concrete reported errors are definitive events to which zfs can respond, rather than relying on timeouts, however abstract or hidden or layered or frustrating. Making the system more deterministic is worthwhile. > What's really needed for ZFS or RAID in general is (a) for drives to > never spend more than x% of their time attempting recovery Sure. When you find where we can buy such a drive, please let us all know. > Because a 7-second-per-read drive will fuck your pool just as badly as > a 70-second-per-read drive: you're going to have to find and unplug it > before the pool will work again. Agreed, to a point. If the drive repeatedly reports errors, zfs can and will respond by taking it offline. Even if it doesn't and you have to manually take it offline, at least you will know which drive is having difficulty. -- Dan.
pgpRUZ3HIUyrp.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
