SV: RAID1 synchronisation - howto OR not necessary?

Gert Lynge gert at
Fri Nov 23 10:22:52 PST 2007

>The disks themselves handle the checksumming to detect bad blocks.
>With modern disks it is *very* rare that a block on the disk goes bad
>without the disk being able to report it it as such.  
>This means that if you have a functioning RAID1 setup and one of the
>disks report a bad block, then the controller can simply read the
>corresponding block from the other disk, and rewrite it to the disk
>with the bad block.  If a disk has problems writing a block it will
>transparently re-map the block to another.
>The problems can occur when one disk in a RAID-array has failed and you
>try to rebuild it from the other disk(s). If you then encounter a bad block
>on that disk you have a problem since you don't have a good copy of that
>This is what verification (which, btw, is not the same as synchronization)
>tries to prevent by reading every block on each disk on a regular basis. 
>Then the RAID controller can recover the data on any bad blocks from the
>other disk(s) in the array.

I've been wondering how to do this with a BIOS assisted soft raid for some
I have a server with ad4 ad6 in a mirror detected as ar0:
ws# atacontrol status ar0
ar0: ATA RAID1 subdisks: ad4 ad6 status: READY
ws# cat /var/run/dmesg.boot
ar0: 76316MB <Intel MatrixRAID RAID1> status: READY
ar0: disk0 READY (master) using ad4 at ata2-master
ar0: disk1 READY (mirror) using ad6 at ata3-master

...and was wondering if dd could not do the job for me?
ws# man dd
     Check that a disk drive contains no bad blocks:
           dd if=/dev/ad0 of=/dev/null bs=1m

What if I run:
dd if=/dev/ad4 /of=/dev/null bs=1m
dd if=/dev/ad6 /of=/dev/null bs=1m

...once a week - will that not verify that the two drives can read all

It would be nice to limit the load (the throughput of dd) though - anyone
know if that is possible? Maybe by pipeing through a second command (I guess
a throughput limiter could easily be programmed?).

    Gert Lynge

More information about the freebsd-questions mailing list