Robert Milkowski wrote:
Saturday, November 4, 2006, 12:46:05 AM, you wrote:
REP> Incidentally, since ZFS schedules the resync iops itself, then it can
REP> really move along on a mostly idle system. You should be able to resync
REP> at near the media speed for an idle system. By contrast, a hardware
REP> RAID array has no knowledge of the context of the data or the I/O
scheduling,
REP> so they will perform resyncs using a throttle. Not only do they end up
REP> resyncing unused space, but they also take a long time (4-18 GBytes/hr for
REP> some arrays) and thus expose you to a higher probability of second disk
REP> failure.
However some mechanism to slow or freeze scrub/resilvering would be
useful. Especially in cases where server does many other things and
not only file serving - and scrub/resilver can take much CPU power on
slower servers.
Something like 'zpool scrub -r 10 pool' - which would mean 10% of
speed.
I think this has some merit for scrubs, but I wouldn't suggest it for resilver.
If your data is at risk, there is nothing more important than protecting it.
While that sounds harsh, in reality there is a practical limit determined by
the ability of a single LUN to absorb a (large, sequential?) write workload.
For JBODs, that would be approximately the media speed.
The big question, though, is "10% of what?" User CPU? iops?
-- richard
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
