Jason,

Sorry for my misunderstanding. Now I get you!
From 
dsl_scan.c(http://fxr.watson.org/fxr/source/common/fs/zfs/dsl_scan.c?v=OPENSOLARIS),
 we
can get following:
   59 int zfs_top_maxinflight = 32;           /* maximum I/Os per top-level */
   60 int zfs_resilver_delay = 2;             /* number of ticks to delay 
resilver */
   61 int zfs_scrub_delay = 4;                /* number of ticks to delay scrub 
*/
   62 int zfs_scan_idle = 50;                 /* idle window in clock ticks */
   63 
   64 int zfs_scan_min_time_ms = 1000; /* min millisecs to scrub per txg */
   65 int zfs_free_min_time_ms = 1000; /* min millisecs to free per txg */
   66 int zfs_resilver_min_time_ms = 3000; /* min millisecs to resilver per txg 
*/
   67 boolean_t zfs_no_scrub_io = B_FALSE; /* set to disable scrub i/o */
   68 boolean_t zfs_no_scrub_prefetch = B_FALSE; /* set to disable srub 
prefetching */
   69 enum ddt_class zfs_scrub_ddt_class_max = DDT_CLASS_DUPLICATE;
   70 int dsl_scan_delay_completion = B_FALSE; /* set to delay scan completion 
*/
   71

Maybe, that is only document we can reference. And my bits are following:

1): Are there ranges for these tunables? Or the ranges vary from different 
hw/sw configuration?
     Or we can try to detect the limits?
2): single tunable is fine-grained enough? Or need aggregation of these 
tunables?

Thanks.

Fred

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Jason Matthews
> Sent: 星期三, 十月 21, 2015 12:46
> To: [email protected]; [email protected]; developer;
> freebsd-fs; zfs-discuss; [email protected]; zfs-
> [email protected]
> Subject: Re: [zfs] RE: granularity of performance penalty from
> resilvering
> 
> 
> I am not sure we are communicating.
> 
> Instead of prioritizing resilvering, de-prioritize resilvering using
> those tunables.
> j.
> 
> On 10/20/2015 7:14 PM, Fred Liu wrote:
> > Yeah, that is a trade-off. Prioritize resilvering high will shorten
> the time window.
> > That means brake your application "temporarily??". Even in current
> > situation, the resilvering eats almost all the IOs.
> >
> >> -----Original Message-----
> >> From: [email protected]
> >> [mailto:[email protected]]
> >> On Behalf Of Jason Matthews
> >> Sent: 星期三, 十月 21, 2015 10:00
> >> To: [email protected]; [email protected];
> >> developer; freebsd-fs; zfs-discuss; [email protected];
> zfs-
> >> [email protected]
> >> Subject: Re: [zfs] RE: granularity of performance penalty from
> >> resilvering
> >>
> >>
> >>
> >> i just sent you the tunables. turn the knobs in the other direction.
> >>
> >> j.
> >>
> >> On 10/20/2015 6:58 PM, Fred Liu wrote:
> >>> This feature is really needed. Even in some low-end RAID
> >>> controllers, the rebuilding penalty is tunable more than the
> >>> high-end enterprise
> >> storage....
> >>>> -----Original Message-----
> >>>> From: [email protected]
> >>>> [mailto:[email protected]]
> >>>> On Behalf Of Jason Matthews
> >>>> Sent: 星期三, 十月 21, 2015 9:53
> >>>> To: [email protected]; [email protected];
> >>>> developer; freebsd-fs; zfs-discuss; [email protected]
> >>>> Subject: Re: [zfs] RE: granularity of performance penalty from
> >>>> resilvering
> >>>>
> >>>>
> >>>> That is the only way to fly...
> >>>>
> >>>> j.
> >>>>
> >>>> On 10/20/2015 6:35 PM, Fred Liu wrote:
> >>>>> Yeah. I want to go the other way. Plus, these settings are only
> >>>>> applicable in illumos.
> >>>>>
> >>>>> Therefore I decide to give up the hybrid( ssd+sata) solution to
> >>>>> underpin applications which need decent RAS.
> >>>>>
> >>>>> I am gonna go all-flash array.
> >>>>>
> >>>>> Thanks.
> >>>>>
> >>>>> Fred
> >>>>>
> >>>>> *From:*Jason Matthews [mailto:[email protected]]
> >>>>> *Sent:* 星期三, 十月21, 2015 9:05
> >>>>> *To:* [email protected]; Fred Liu;
> >>>>> [email protected]; developer; freebsd-fs;
> >>>>> zfs-discuss
> >>>>> *Subject:* Re: [zfs] RE: granularity of performance penalty from
> >>>>> resilvering
> >>>>>
> >>>>>
> >>>>>
> >>>>> you could look at these tunables (not the settings themselves)...
> >>>>>
> >>>>> these settings actually make resilvers have a higher priority.
> You
> >>>>> obviously would want to go the other way.
> >>>>>
> >>>>> j.
> >>>>>
> >>>>> |* Prioritize resilvering by setting the delay to zero| set
> >>>>> |zfs:zfs_resilver_delay = 0 |
> >>>>>
> >>>>> * Prioritize scrubs by setting the delay to zero set
> >>>>> zfs:zfs_scrub_delay = 0
> >>>>>
> >>>>> |* resilver for five seconds per TXG| set
> >>>>> |zfs:zfs_resilver_min_time_ms = 5000|
> >>>>>
> >>>>>
> >>>>> |echo zfs_resilver_delay/w0 | mdb -kw| echo zfs_scrub_delay/w0
> >>>>> ||mdb
> >>>>> |-kw| echo zfs_top_maxinflight/w7f |mdb -kw| echo
> >>>>> |zfs_resilver_min_time_ms/w1388 |mdb -kw|
> >>>>>
> >>>>> On 10/19/2015 11:49 PM, Fred Liu wrote:
> >>>>>
> >>>>>       Yes, “zpool scrub –s” can stop the resilvering.
> >>>>>
> >>>>>       *From:*Fred Liu
> >>>>>       *Sent:* 星 期二, 十月20, 2015 12:15
> >>>>>       *To:* '[email protected]
> >>>>>       <mailto:[email protected]>'; developer;
> >>>>> illumos-
> >> zfs;
> >>>>>       freebsd-fs; zfs-discuss
> >>>>>       *Subject:* granularity of performance penalty from
> >>>>> resilvering
> >>>>>
> >>>>>       Sorry if is a duplicate thread.
> >>>>>
> >>>>>       The last suffering has been lasted for two weeks for we
> >>>>> replaced
> >>>> a
> >>>>>       6TB HDD.
> >>>>>
> >>>>>       There should be some IO throttle measure from ZFS software
> >> stack.
> >>>>>       At least, we can try to stop resilvering like scrubbing
> >>>>>
> >>>>>       if the realization is quiet complicated.
> >>>>>
> >>>>>       Besides that, will nice zil/cache be relief?
> >>>>>
> >>>>>       Thanks.
> >>>>>
> >>>>>       Fred
> >>>>>
> >>>>> *illumos-zfs* | Archives
> >>>>> <https://www.listbox.com/member/archive/182191/=now>
> >>>>> <https://www.listbox.com/member/archive/rss/182191/22567878-
> >> 8480fd5f
> >>>>> | Modify
> >>>>>
> >>>> <https://www.listbox.com/member/?&;
> >>>> f5b912c9>
> >>>>> Your Subscription         [Powered by Listbox]
> <http://www.listbox.com>
> >>>>>
> >>>> _______________________________________________
> >>>> [email protected] mailing list
> >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-fs
> >>>> To unsubscribe, send any mail to "freebsd-fs-
> >> [email protected]"
> >>> -------------------------------------------
> >>> illumos-zfs
> >>> Archives: https://www.listbox.com/member/archive/182191/=now
> >>> RSS Feed:
> >>> https://www.listbox.com/member/archive/rss/182191/22567878-8480fd5f
> >>> Modify Your Subscription:
> >>>
> >> https://www.listbox.com/member/?&;
> >>> f5b912c9 Powered by Listbox: http://www.listbox.com
> >> _______________________________________________
> >> [email protected] mailing list
> >> https://lists.freebsd.org/mailman/listinfo/zfs-devel
> >> To unsubscribe, send any mail to "[email protected]"
> >
> > -------------------------------------------
> > illumos-zfs
> > Archives: https://www.listbox.com/member/archive/182191/=now
> > RSS Feed:
> > https://www.listbox.com/member/archive/rss/182191/22567878-8480fd5f
> > Modify Your Subscription:
> >
> https://www.listbox.com/member/?member_id=22567878&id_secret=22567878-
> > f5b912c9 Powered by Listbox: http://www.listbox.com
> 
> _______________________________________________
> [email protected] mailing list
> https://lists.freebsd.org/mailman/listinfo/zfs-devel
> To unsubscribe, send any mail to "[email protected]"
_______________________________________________
developer mailing list
[email protected]
http://lists.open-zfs.org/mailman/listinfo/developer

Reply via email to