The scrub that found nothing

Once a month the NAS at home runs zpool scrub tank. This month's report:

  scan: scrub repaired 0B in 03:12:47 with 0 errors

Zero, as usual. I keep the schedule anyway, for three reasons.

• Silent rot. A scrub reads every allocated block and checks it against its checksum. Data that is rarely read can go bad unnoticed until the day it is needed — and by then the second disk of the mirror may have the same problem.
• A free health test. A drive that starts throwing read errors during a scrub gets replaced while the pool is still redundant, not in the middle of a resilver.
• A trend line. The duration matters more than the result. When a scrub that used to take three hours takes five, something is wrong with a disk, a cable or the controller.

Before adding your own timer, check what the distribution already does: Debian's zfsutils-linux ships /etc/cron.d/zfsutils-linux, which scrubs every pool on the second Sunday of the month. Two schedules mean two scrubs, and a scrub started while another runs just fails.