>>>>> "re" == Richard Elling <[EMAIL PROTECTED]> writes:
re> unrecoverable read as the dominant disk failure mode. [...]
re> none of the traditional software logical volume managers nor
re> the popular open source file systems (other than ZFS :-)
re> address this problem.
Other LVM's should address unrecoverable read errors as well or better
than ZFS, because that's when the drive returns an error instead of
data. 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. 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. I would expect all the software volume managers
including ZFS fail to do this. It's really hard to test without
somehow getting a drive that returns read errors frequently, but isn't
about to die within the month---maybe ZFS should have an error
injector at driver-level instead of block-level, and a model for
time-based errors. 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.
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.
The Netapp paper focused on when drives silently return incorrect
data, which is different than returning an error. Both Netapp and ZFS
do checksums to protect from this. However Netapp never claimed this
failure mode was more common than reported unrecoverable read errors,
just that it was more interesting. I expect it's much *less* common.
Further, we know Netapp loaded special firmware into the enterprise
drives in that study because they wanted the larger sector size. They
are likely also loading special firmware into the desktop drives to
make them return errors sooner than 30 seconds. so, it's not
improbable that the Netapp drives are more prone to deliver silently
corrupt data instead of UNC/seek errors compared to off-the-shelf
drives.
Finally, for the Google paper, silent corruption ``didn't even make
the chart.'' so, saying something didn't make your chart and saying
that it doesn't happen are two different things, and your favoured
conclusion has a stake in maintaining that view, too.
pgpsI3gZXY8Ue.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
