On 03 January, 2009 - Jake Carroll sent me these 5,9K bytes: > Hi. > > Running snv_104 x86 against some very generic hardware as a testbed for some > fun projects and as a home fileserver. Rough specifications of the host: > > * Intel Q6600 > * 6GB DDR2 > * Multiple 250GB, 500GB SATA connected HDD's of mixed vendors > * Gigabyte GA-DQ6 series motherboard > * etc. > > The problem or interesting scenario. > > I decided to cron a zpool scrub of all three zpool's on the host system > simultaneously. Something like this: > > 00 01 * * * /usr/sbin/zpool scrub backups > /dev/null 2>&1 > 00 01 * * * /usr/sbin/zpool scrub ztank > /dev/null 2>&1 > 00 01 * * * /usr/sbin/zpool scrub zebraware_root > /dev/null 2>&1 > > So, we know from reading documentation that: > > [i]Because scrubbing and resilvering are I/O-intensive > operations, ZFS only allows one at a time. If a scrub is > already in progress, the "zpool scrub" command ter- > minates it and starts a new scrub. If a resilver is in > progress, ZFS does not allow a scrub to be started until > the resilver completes[/i] > > Please note the "[b]ZFS only allows one at a time[/b]" statement. > Maybe relevant to what I'm about to explain. Maybe not.
One at a time per pool. > So, my puzzling thoughts: > > 1. Am I just experiencing some form of crappy consumer grade > controller I/O limitations or an issue of the controllers on this > consumer grade kit not being up to the task of handling multiple > scrubs occurring on different filesystems at any given time>? Probably. When getting too much load, you might get some overhearing or something. Shouldn't happen if the hw + drivers works as expected.. You will probably get similar results if you start too much regular io.. > 2. Is this natural and to be expected (and moreover, am I breaking the > rules) by attempting to scrub more than one pool at once - ergo > [i]"well, what did you expect?[/i]" I scrub more than one pool at a time all the time, no issues. > Out of fear and sensibility, I've never simultaneously scrubbed > production pools on our 6 series arrays at work, or for anything that > actually matters - but I am interested in getting to the bottom of > this, all the same. /Tomas -- Tomas Ögren, st...@acc.umu.se, http://www.acc.umu.se/~stric/ |- Student at Computing Science, University of Umeå `- Sysadmin at {cs,acc}.umu.se _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss