Hello Richard, 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 >> 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. REP> I think this has some merit for scrubs, but I wouldn't suggest it for resilver. REP> If your data is at risk, there is nothing more important than protecting it. REP> While that sounds harsh, in reality there is a practical limit determined by REP> the ability of a single LUN to absorb a (large, sequential?) write workload. 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 right. 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. -- Best regards, Robert mailto:[EMAIL PROTECTED] http://milek.blogspot.com _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
