Eric Schrock wrote:

1. Some sort of background process to proactively find errors on disks
   in use by ZFS.  This will be accomplished by a background scrubbing
   option, dependent on the block-rewriting work Matt and Mark are
   working on.  This will allow something like "zpool set scrub=2weeks",
   which will tell ZFS to "scrub my data at an interval such that all
   data is touched over a 2 week period".

Obviously, scrubbing and correcting "hard" errors that result in
ZFS checksum errors is very beneficial. However, it won't address the
case of "soft" errors when the disk returns correct data but
observes some problems reading it. There are at least two good reasons
to pay attention to these "soft" errors:

a) Preemptive detection and rewriting of partially defective but
   still correctable sectors may prevent future data loss. Thus,
   it improves perceived reliability of disk drives, which is
   especially important in the JBOD case (including a single-drive JBOD).

b) It is not uncommon for such successful reads of partially defective
   media to happen only after several retries. It is somewhat unfortunate
   that there is no simple way to tell the drive how many times to retry.
   Firmware in ATA/SATA drives, used predominantly in single-disk PCs,
   will typically do a heroic effort to retrieve the data. It will
   make numerous attempts to reposition the actuator, recalibrate the
   head current, etc. It can take up to 20-40 seconds! Such strategy
   is reasonable for a desktop PC but in it happens in an busy
   enterprise file server it results in a temporary availability loss
   (the drive freezes for up 20-40 seconds every time you try to
   read this sector). Also, this strategy does not make any sense if
   a RAID group in which the drive participates has redundant data
   elsewhere, which is why SCSI/FC drives give up after a few retries.

One can detect (and repair) such problematic areas on disk by monitoring
the  SMART counters during scrubbing, and/or by monitoring physical
read timings (looking for abnormally slow ones).

-- Olaf

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to