disk scrubber for Linux?

Michael ODonnell michael.odonnell at comcast.net
Fri Dec 9 09:10:01 EST 2005


The basic premises leading me to investigate scrubbers:

  #1. Storage devices aren't perfect.
  #2. RAID won't always save you from #1.
  #3. Backups won't always save you from #2.

As has already been mentioned, item #1 is such a fact of
life that drives come equipped with spare sectors, tracks
and cylinders.  It's normal for disks to remain in service
with at least one such region that's been remapped; sometimes
they're mentioned on a sticker printed at the factory.  It's also
normal for sectors to remain in use despite permanent single-bit
errors within them, as long as data can be reliably laid down and
recovered from them via CRC.  Devices with such remapped regions
and bit errors are not considered to "degraded" or in need of
emergency replacement and often go on to give good service over
normal lifespans.  Sectors can also have transient errors caused
by cosmic rays or Flying Spaghetti Monster's noodly appendage;
although the data written on that occasion are lost, rewriting
that sector is all that's needed to bring it back into service.

Item #2 refers to the small but nonzero probability that the
redundant nature of a RAID could actually hide the fact that
data in a given block are no longer retrievable, because the
read request for the data in question might be satisfied from
the disk without the fault.

Item #3 is a direct consequence of #2, and if such a crypto-
failure leads you to incorrectly conclude that it's OK to
swap in a new disk and sync it to the disk with the fault,
you're unhappy.  A scrubber's gratuitous reads could alert you
to the fault in time to either rewrite the sector, remap it or
take the drive out of service in timely fashion.

Yes, we're talking about low-probability events here; none of
this means everybody has a screaming need for a scrubber, just
that in some situations it's worth investigating.

 



More information about the gnhlug-discuss mailing list