Robert Milkowski wrote:
Hello Torrey,
Friday, November 10, 2006, 11:31:31 PM, you wrote:
TM> Robert Milkowski wrote:
Also scrub can consume all CPU power on smaller and older machines and
that's not always what I would like.
REP> The big question, though, is "10% of what?" User CPU? iops?
AH> Probably N% of I/O Ops/Second would work well.
Or if 100% means full speed, then 10% means that expected time should
be approximately 10x more (instead 1h make it 10h).
It would be more intuitive than specifying some numbers like IOPS,
etc.
TM> In any case you're still going to have to provide a tunable for this
TM> even if the resulting algorithm works well on the host side. Keep in
TM> mind that a scrub can also impact the array(s) you're filesystem lives
TM> on. If all my ZFS systems started scrubbing at full speed - Because they
TM> thought they weren't busy - at the same time it might cause issues with
TM> other I/O on the array itself.
Tunable in a form of pool property, with default 100%.
On the other hand maybe simple algorithm Veritas has used is good
enough - simple delay between scrubing/resilvering some data.
I think a not-to-convoluted algorithm as people have suggested would be
ideal and then let people override it as necessary. I would think a 100%
default might be a call generator but I'm up for debate. ("Hey my array
just went crazy. All the lights are blinking but my application isn't
doing any I/O. What gives?")
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
