On Thu, Mar 18, 2010 at 05:21:17AM -0700, Tonmaus wrote: > > No, because the parity itself is not verified. > > Aha. Well, my understanding was that a scrub basically means reading > all data, and compare with the parities, which means that these have > to be re-computed. Is that correct?
A scrub does, yes. It reads all data and metadata and checksums and verifies they're correct. A read of the pool might not - for example, it might: - read only one side of a mirror - read only one instance of a ditto block (metadata or copies>1) - use cached copies of data or metadata; for a long-running system it might be a long time since some metadata blocks were ever read, if they're frequently used. Roughly speaking, reading through the filesystem does the least work possible to return the data. A scrub does the most work possible to check the disks (and returns none of the data). For the OP: scrub issues low-priority IO (and the details of how much and how low have changed a few times along the version trail). However, that prioritisation applies only within the kernel; sata disks don't understand the prioritisation, so once the requests are with the disk they can still saturate out other IOs that made it to the front of the kernel's queue faster. If you're looking for something to tune, you may want to look at limiting the number of concurrent IO's handed to the disk to try and avoid saturating the heads. You also want to confirm that your disks are on an NCQ-capable controller (eg sata rather than cmdk) otherwise they will be severely limited to processing one request at a time, at least for reads if you have write-cache on (they will be saturated at the stop-and-wait channel, long before the heads). -- Dan.
pgpoGKGntteaH.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
