Hello again, I am still concerned if my points are being well taken.
> If you are concerned that a > single 200TB pool would take a long > time to scrub, then use more pools and scrub in > parallel. The main concern is not scrub time. Scrub time could be weeks if scrub just would behave. You may imagine that there are applications where segmentation is a pain point, too. > The scrub will queue no more > han 10 I/Os at one time to a device, so devices which > can handle concurrent I/O > are not consumed entirely by scrub I/O. This could be > tuned lower, but your storage > is slow and *any* I/O activity will be noticed. There are a couple of things I maybe don't understand, then. - zpool iostat is reporting more than 1k of outputs while scrub - throughput is as high as can be until maxing out CPU - nominal I/O capacity of a single device is still around 90, how can 10 I/Os already bring down payload - scrubbing the same pool, configured as raidz1 didn't max out CPU which is no surprise (haha, slow storage...) the notable part is that it didn't slow down payload that much either. - scrub is obviously fine with data added or deleted during a pass. So, it could be possible to pause and resume a pass, couldn't it? My conclusion from these observations is that not only disk speed counts here, but other bottlenecks may strike as well. Solving the issue by the wallet is one way, solving it by configuration of parameters is another. So, is there a lever for scrub I/O prio, or not? Is there a possibility to pause scrub passed and resume? Regards, Tonmaus -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
