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?
Probably N% of I/O Ops/Second would work well.
> Just slower the reate resilvering/scrub is done.
> Insert some kind of delay as some one else suggested.
>
>
Al Hopper Logical Approach Inc, Plano, TX. [EMAIL PROTECTED]
Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT
OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005
OpenSolaris Governing Board (OGB) Member - Feb 2006
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
