Tuesday, November 7, 2006, 5:19:07 PM, you wrote:
REP> 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
>> 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
>> 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
REP> I think this has some merit for scrubs, but I wouldn't suggest it for
REP> If your data is at risk, there is nothing more important than protecting
REP> While that sounds harsh, in reality there is a practical limit determined
REP> the ability of a single LUN to absorb a (large, sequential?) write
REP> For JBODs, that would be approximately the media speed.
I can't agree. I have some performance sensitive environments and I
know that during the day I do not want loose performance even if it
means longer resilvering times. That's exactly what I do on HW RAID
controller. In other environments I do want to resilver ASAP, you're
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?
Just slower the reate resilvering/scrub is done.
Insert some kind of delay as some one else suggested.
zfs-discuss mailing list