Scrubbing may be for wimps, but wimps are the people who get to keep their data. Scrubbing is actually really important for that. Scrubbing is, as cracauer already said, to find problems earlier. Before more and bigger problems can accumulate, and overwhelm whatever redundancy mechanism is there to deal with problems (redundancy can be RAID, backups, or the redundancy inherent in file system metadata). This applies to detecting disk drive hardware problems (on both spinning rust and SSDs), silent data (or metadata) corruptions (which exist, and in a large enough system are measurably common), and software bugs and user errors. In a nutshell, the reliability of a redundant storage system depends critically on the time required to repair damage (which is why the MTTR is discussed in the appendix of the original RAID paper), and scrubbing allows one to begin repairs sooner, effectively reducing the MTTR. There is a really nice paper published by some people at NetApp about 15 years ago demonstrating how scrubbing increases data durability.
Now, how often or quickly should one scrub? That's a tradeoff between three things. The more often one scrubs, the sooner one detects problems, so from that viewpoint one should scrub as fast as possible. On the other hand, scrubbing can interfere with the performance of the real user workload (and use more energy = carbon footprint, if one worries about such things). And on certain hardware types, the reads that scrubbing does can cause wear on the drive itself, so scrubbing overly quickly may actually be counter-productive. Whether reads are bad for the devices depends on fine details. On SSDs, at the hardware (flash chip) level, reads do not contribute to wearout. But a continuous stream of reads may keep the controller overly busy, preventing it from doing garbage collection (internal compaction) efficiently, and inefficient compaction at the last minute may require more block erases (depends on the fine details of how the FTL is implemented). On spinning disks, it was long thought that reads do not create wear of heads and platters. We now know this to be false, even reading a disk will cause transfer of lubricant between heads and platters and making the surface less flat (although the effect might be worse for writes, due to the reduced fly height when writing), which is why current disks have limits on the total IO throughput to maintain warranty coverage (commonly 550 TB/year). This seems to hold both for conventional disks as well as shingled (SMR) disks, but there is anecdotal evidence that SMR-enabled hardware may be more reliable when used correctly (full zone writes). In the near future, when HAMR/MAMR disks come into production, it is likely the balance will flip again, with writes having a much bigger effect than reads again. To my knowledge, there is no published study on the optimal tradeoff between scrub frequency and durability. Even if it were published, the result depends on a precarious balance between the mechanisms for data destruction (vibration, temperature cycles causing hardware problems, the quality of the storage software stack) versus the thoroughness of scrub (for example, does it validate checksums and the whole metadata graph, like fsck), to the results could not be generalized.
For amateur and small-scale users, the much bigger question is: Does scrub interfere with file system performance to an unacceptable level? The answer is clearly: it depends on hardware (how many disks, how fast, what disk interface, CPU performance), and performance expectations (do I need near-perfect speed, or is getting 10 MByte/s reliably good enough). Just as one example, on my home server (very small, 2 enterprise near-line disks in a mirror, 1.8 GHz Atom CPU and 4 gig of RAM), the system became unpleasantly slow when scrubbing. I had to adjust ZFS scrub as follows to get the system to feel responsive:
Code:
vfs.zfs.no_scrub_prefetch: leave at default 0
vfs.zfs.scrub_delay: 20 (default 4)
vfs.zfs.scan_idle: 1000 (default 50)
YMMV, so don't follow those values blindly. With these settings, I scrub the SSD-based file systems every 3 days, and the disk-based 3TB mirror file system once a week, and all scrubs finish in less than 24 hours (typically much less, I start them after 1am, and they are done by morning). I know I should probably change the schedule to do the disk every 2-3 weeks, but my silly little scrubbing script only looks at the weekday, and I haven't had the 10 minutes needed to teach it to count to 3.
And: I have one "remote" backup disk attached to my server (the disk is physically 2m away from the server, inside a thick-walled safe). I know that scrubbing that disk for an hour increases its temperature, from typically 32 to over 40 degrees. Is that a bad thing? I don't know; the effect of temperature on disks is complex.
