Hello Al, Friday, November 10, 2006, 2:21:38 PM, you wrote:
AH> On Thu, 9 Nov 2006, Robert Milkowski wrote: >> 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? 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. Additionally setting it to 0 means freeze, then setting it above 0% means continue (continue not start from the beginning). -- 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
