Scrubs are run at very low priority and yield very quickly in the presence of
So I really would not expect to see scrub create any impact on an other type of
Resilvering will more aggressively push forward on what is has to do, but
resilvering does not need to
read any of the data blocks on the non-resilvering vdevs.
Le 11 juin 2012 à 09:05, Jim Klimov a écrit :
> 2012-06-11 5:37, Edward Ned Harvey wrote:
>>> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
>>> boun...@opensolaris.org] On Behalf Of Kalle Anka
>>> Assume we have 100 disks in one zpool. Assume it takes 5 hours to scrub
>>> disk. If I scrub the zpool, how long time will it take?
>>> Will it scrub one disk at a time, so it will take 500 hours, i.e. in
>> sequence, just
>>> serial? Or is it possible to run the scrub in parallel, so it takes 5h no
>>> how many disks?
>> It will be approximately parallel, because it's actually scrubbing only the
>> used blocks, and the order it scrubs in will be approximately the order they
>> were written, which was intentionally parallel.
> What the other posters said, plus: 100 disks is quite a lot
> of contention on the bus(es), so even if it is all parallel,
> the bus and CPU bottlenecks would raise the scrubbing time
> somewhat above the single-disk scrub time.
> Roughly, if all else is ideal (i.e. no/few random seeks and
> a fast scrub at 100Mbps/disk), the SATA3 interface at 6Gbit/s
> (on the order of ~600Mbyte/s) will be maxed out at about
> 6 disks. If your disks are colocated on one HBA receptacle
> (i.e. via a backplane), this may be an issue for many disks
> in an enclosure (a 4-lane link will sustain about 24 drives
> at such speed, and that's not the market's max speed).
> Further on, the PCI buses will become a bottleneck and the
> CPU processing power might become one too, and for a box
> with 100 disks this may be noticeable, depending on the other
> architectural choices, components and their specs.
> zfs-discuss mailing list
zfs-discuss mailing list