--On 08 September 2008 07:30 -0700 Richard Elling <[EMAIL PROTECTED]> wrote:
> This seems like a reasonable process to follow, I would have done > much the same. > [caveat: I've not examined the FreeBSD ZFS port, the following > presumes the FreeBSD port is similar to the Solaris port] > ZFS does not have its own timeouts for this sort of problem. > It relies on the underlying device drivers to manage their > timeouts. So there was not much you could do at the ZFS level > other than detach the disk. Ok, I'm glad I'm finally getting the hang of ZFS, and 'did the right thing(tm)'. Is there any tunable on ZFS that will tell it "If you get more than x/y/z Read, Write or Checksum errors" - detach the drive as 'failed'? Maybe on a per-drive basis? It'd probably need some way for admin to override it (i.e. force it to be ignored)? - for those times where you either have to, or for a drive you know will at least stand a chance of reading the rest of the surface 'past' the errors. This would probably be set quite low for 'consumer' grade drives, and moderately higher for 'enterprise' drives that don't "go out to lunch" for extended periods while seeing if they can recover a block. You could even default it to 'infinity' if that's what the current level is. It'd certainly have saved me a lot of time if the number of errors on the drive had past a relatively low figure, and it just ditched the drive... One other random thought occurred to me when this happened - if I detach a drive, does ZFS have to update some meta-data on *all* the drives for that pool (including the one I've detached) to know it's been detached? (if that makes sense). That might explain why the 'detach' I issued just hung (if it had to update meta-data on the drive I was removing, it probably got caught in the wash of failing I/O timing out on that device). -Karl _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
