Mattias Pantzare wrote: > 2008/8/26 Richard Elling <[EMAIL PROTECTED]>: > >>> Doing a good job with this error is mostly about not freezing >>> the whole filesystem for the 30sec it takes the drive to report the >>> error. >>> >> That is not a ZFS problem. Please file bugs in the appropriate category. >> > > Who's problem is it? It can't be the device driver as that has no > knowledge of zfs > filesystems or redundancy. >
In most cases it is the drivers below ZFS. For an IDE disk it might be cmdk(7d) over ata(7d). For a USB disk it might be sd(7d) over scsa2usb(7d) over ehci(7d). printconf -D will show which device drivers are attached to your system. If you search the ZFS source code, you will find very little error handling of devices, by design. >>> Either the drives should be loaded with special firmware that >>> returns errors earlier, or the software LVM should read redundant data >>> and collect the statistic if the drive is well outside its usual >>> response latency. >>> >> ZFS will handle this case as well. >> > > How is ZFS handling this? Is there a timeout in ZFS? > Not for this case, but if configured to manage redundancy, ZFS will "read redundant data" from alternate devices. A business metric such as reasonable transaction latency would live at a level above ZFS. >>> One thing other LVM's seem like they may do better >>> than ZFS, based on not-quite-the-same-scenario tests, is not freeze >>> filesystems unrelated to the failing drive during the 30 seconds it's >>> waiting for the I/O request to return an error. >>> >>> >> This is not operating in ZFS code. >> > > In what way is freezing a ZFS filesystem not operating in ZFS code? > > Notice that he wrote filesystems unrelated to the failing drive. > > At the ZFS level, this is dictated by the failmode property. >>> In terms of FUD about ``silent corruption'', there is none of it when >>> the drive clearly reports a sector is unreadable. Yes, traditional >>> non-big-storage-vendor RAID5, and all software LVM's I know of except >>> ZFS, depend on the drives to report unreadable sectors. And, >>> generally, drives do. so let's be clear about that and not try to imply >>> that the ``dominant failure mode'' causes silent corruption for >>> everyone except ZFS and Netapp users---it doesn't. >>> >>> >> In my field data, the dominant failure mode for disks is unrecoverable >> reads. If your software does not handle this case, then you should be >> worried. We tend to recommend configuring ZFS to manage data >> redundancy for this reason. >> > > He is writing that all software LVM's will handle unrecoverable reads. > I agree. And if ZFS is configured to manage redundancy and a disk read returns EIO or the checksum does not match, then ZFS will attempt to read from the redundant data. However, not all devices return error codes which indicate unrecoverable reads. Also, data corrupted in the data path between media and main memory may not have an associated error condition reported. I find comparing unprotected ZFS configurations with LVMs using protected configurations to be disingenuous. > What is your definition of unrecoverable reads? > I wrote data, but when I try to read, I don't get back what I wrote. -- richard _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
