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)
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).
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:
copies=2
or more)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).