alt Hacker News>Most systems that include ZFS schedule scrubs once per month. This frequency is appropriate for many environments, but high churn systems may require more frequent scrubs.
Is there a more specific 'rule of thumb' for scrub frequency? What variables should one consider?
Replies
Once a month might be too high because HDDs are rated at ~ 180 TB workload/year. Remember, the workload/year limit includes read & writes and doesn't vary much by capacity, so a 10 TB HDD scrubbed monthly consumes 67% of the workload, let alone any other usage.
Scrubbing every quarter is usually sufficient without putting high wear on the HDD.
Once a month is fine ("/etc/cron.monthly/zfs-scrub"):
#!/bin/bash
#
# ZFS scrub script for monthly maintenance
# Place in /etc/cron.monthly/zfs-scrub
POOL="storage"
TAG="zfs-scrub"
# Log start
logger -t "$TAG" -p user.notice "Starting ZFS scrub on pool: $POOL"
# Run the scrub
if /sbin/zpool scrub "$POOL"; then
logger -t "$TAG" -p user.notice "ZFS scrub initiated successfully on pool: $POOL"
else
logger -t "$TAG" -p user.err "Failed to start ZFS scrub on pool: $POOL"
exit 1
fi
exit 0The cost of a scrub is just a flurry of disk reads and a reduction in performance during a scrub.
If this cost is affordable on a daily basis, then do a scrub daily. If it's only affordable less often, then do it less often.
(Whatever the case: It's not like a scrub causes any harm to the hardware or the data. It can run as frequently as you elect to tolerate.)
Total pool size and speed. Less data scrubs faster, as do faster disks or disk topology (a 3 way stripe of nvme will scrub faster than a single sata ssd)
For what its worth, I scrub daily mostly because I can. It's completely overkill, but if it only takes half an hour, then it can run in the middle of the night while I'm sleeping.
Once a month seems like a reasonable rule of thumb.
But you're balancing the cost of the scrub vs the benefit of learning about a problem as soon as possible.
A scrub does a lot of I/O and a fair amount of computing. The scrub load competes with your application load and depending on the size of your disk(s) and their read bandwidth, it may take quite some time to do the scrub. There's even maybe some potential that the read load could push a weak drive over the edge to failure.
On my personal servers, application load is nearly meaningless, so I do an about monthly scrub from cron which I think will only scrub one zpool at a time per machine, which seems reasonable enough to me. I run relatively large spinning disks, so if I scrubbed on a daily basis, the drives would spend most of the day scrubbing and that doesn't seem reasonable. I haven't run ZFS in a work environment... I'd have to really consider how the read load impacted the production load and if scrubbing with limits to reduce production impact would complete in a reasonable amount of time... I've run some systems that are essentially alwayd busy and if a scrub would take several months, I'd probably only scrub when other systems indicate a problem and I can take the machine out of rotation to examine it.
If I had very high reliability needs or a long time to get replacement drives, I might scrub more often?
If I was worried about power consumption, I might scrub less often (and also let my servers and drives go into standby). The article's recommendation to scan at least once every 4 months seems pretty reasonable, although if you have seriously offline disks, maybe once a year is more approachable. I don't think I'd push beyond that, lots of things don't like to sit for a year and then turn on correctly.