I found no details on how repairing works and what the requirements are from the docs.

For automatic repairs from a scrub do I need to mirror? RAIDZ? Either? Neither (do the checksums themselves contain parity)?


There is no parity on ZFS blocks so they are not "self repairing".

Scrubbing try to repair corruption errors by relocating blocks with an incorrect checksum elsewhere. It can only do it if a sane copy of the faulty blocks exist on the pool.

The chance for the latter to be true is quite high if you are using redundancy (mirroring or raidz) but is still present for single device pools or stripes if the checksum error affects:

  • a metadata block as they are (at least) duplicated by default
  • a data block from a dataset configured with ditto blocks (copies=2 or more)
  • "relocating blocks elsewhere" - does ZFS thereafter permanently blacklist the original location of the blocks? – Yang Jun 7 '13 at 6:34
  • There is no blacklist I'm aware of at the ZFS level. That would probably make no sense as the disk hardware already maintains such a list for the errors it can detect and remap the faulty sectors to different spare ones in such case. Otherwise, when the error is spurious and undetected by the hardware, the sector will be reused. – jlliagre Jun 7 '13 at 12:13
  • 1
    "ZFS does provide checksumming to prevent silent data corruption, there is no parity nor a mirror to rebuild your data from in the event of a physical disk failure." - zfsbuild.com/2010/05/26/zfs-raid-levels - This sounds incorrect, should "prevent" actually be "detect"? There is nothing it can do to prevent data corruption in a striped setup, correct? – AaronLS Jun 11 '13 at 0:00
  • 1
    There is indeed nothing to prevent data corruption but checksumming allows preventing silent data corruption which is a different statement. Corruption can still occur but don't stay unnoticed and ZFS won't deliver corrupted data. – jlliagre Jun 11 '13 at 6:01

Scrubbing doesn't repair corruption errors, it only detects them. If there's a valid redundant copy of the data available (mirror, raidz, etc) then the corrupted data would be discarded.

When the scrub is done, if bad data was found and discarded a resilvering operation is triggered. This restores redundancy to an array (mirror, raidz, etc). Since the scrub triggers this behavior, you could call it part of the same operation, but internally it is definitely a separate process.

Scrubbing should prompt the underlying storage to report SMART and URE errors if they exist. URE would prompt marking a disk failed (and automatically replacing it if there's a spare available). SMART errors have to be monitored for separately (usually via smartd or similar).

  • You said it only detects and discards the bad data. It doesn't restore them from the redundant copy? So in a mirror, some bad data on drive A is discarded, leaving only the copy on drive B? This means if drive B fails then those blocks are lost permanently? – AaronLS Jun 11 '13 at 0:07
  • Updated to be more clear. Also, whole drive failure is uncommon. UREs are orders of magnitude more common in platter drives (newer SSDs this is also the case, though UREs are less common in SSDs than UWEs). – Chris S Jun 11 '13 at 2:31

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.