I'm not saying that a resilver is stress-free, but rather that it's no (or not significantly) more stressful to those disks than scrubs, which are a routine maintenance operation--and that's in response to the claim I've often seen made that resilvers are so uniquely stressful that they'll kill at least one of the remaining disks, destroying your pool.
There *may* be some differences, and significant ones at that. A resilver and a scrub are very similar in that they walk the pool in a virtually identical manner. We agree, I assume, and this seems to be your point. However, when resilvering, or even when just repairing checksum errors during normal read operations, you are also doing an additional write operation and some other stuff.
For a single disk, writing a single sector shouldn't be terribly hard. Again, I'm going to assume we can see eye to eye on that.
However, for a single SMR disk, writing a single sector involves rewriting the entire shingle, and we already know that this can get very hard on pools, even outside of a scrub operation, if more than a small number of rewrites are involved. This is what led to the original kerfuffle about SMR disks: people had pools that were failing to resilver, even if they had RAIDZ2 or RAIDZ3 protection.
Worse, for even a CMR disk, the sustained write activity increases stress particularly on the target (drive being replaced), increasing temperatures. It is not just a function of reading the existing data sectors and verifying the parity sectors. It is reading the block's sectors, back-calculating the missing data or parity sectors, and then writing that out to the replaced disk. This is more work than just reading all the disks. Reading is relatively trite and some of it is mitigated by drive and host caching. Writing semirandom sectors to rebuild ZFS blocks typically requires a seek for each ZFS block, which may be harder on the drive being written to. More work equals more heat.
Finally, resilvers on mirrors are somewhat easier than RAIDZ because you might only be involving two or three disks (meaning only two or three disks are running warm). RAIDZ, on the other hand, involves each disk in the vdev, and because the process is slower due to the nature of RAIDZ, all the component drives run busier, for longer, get warmer, and it just isn't really a great thing for them.
Think about it this way: You are already running in a degraded mode when a resilver is going on, so the risk of further degradation is more serious than when you're just doing a scrub and reading all the data. Scrubbing a RAIDZ2 that has no errors is pretty safe. However, yank one of those disks out, simulating a disk failure, and you suddenly have something that resembles a RAIDZ1 in terms of redundancy. Now take a hammer and start tapping on one of the other drives to represent an already marginal drive. How certain are you that the pool will survive? 90%? 95%? Fine. You have every right to decide on whatever level of resiliency floats yer boat. But it's important to understand that while your system is degraded, it is DEGRADED in multiple ways -- slower performance, less resiliency. It's easy to think "oh but it's RAIDZ2" and pretend this isn't a thing. But fate has this tendency to pick on the unprepared. If you go full on RAIDZ3 with a warm spare, you'll probably never see a disk fail. That's no fun for fate. It's the goober who decides to rely on RAIDZ1, where a disk fails, and then just one more bad thing happens during resilver, and the pool consistency is now in an indeterminate state. Maybe it's okay for those blocks to come back as all zeroes. Maybe not.
www.truenas.com
