<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 22, 2016, at 5:00 AM, Stephan Budach <<a href="mailto:stephan.budach@jvm.de" class="">stephan.budach@jvm.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Am 21.04.16 um 18:36 schrieb Richard Elling:<br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">On Apr 21, 2016, at 7:47 AM, Chris Siebenmann <<a href="mailto:cks@cs.toronto.edu" class="">cks@cs.toronto.edu</a>> wrote:<br class=""><br class="">[About ZFS scrub tunables:]<br class=""><blockquote type="cite" class="">Interesting read - and it surely works. If you set the tunable before<br class="">you start the scrub you can immediately see the thoughput being much<br class="">higher than with the standard setting. [...]<br class=""></blockquote>It's perhaps worth noting here that the scrub rate shown in 'zpool<br class="">status' is a cumulative one, ie the average scrub rate since the scrub<br class="">started. As far as I know the only way to get the current scrub rate is<br class="">run 'zpool status' twice with some time in between and then look at how<br class="">much progress the scrub's made during that time.<br class=""></blockquote>Scrub rate measured in IOPS or bandwidth is not useful. Neither is a reflection<br class="">of the work being performed in ZFS nor the drives.<br class=""><br class=""><blockquote type="cite" class="">As such, increasing the scrub speed in the middle of what had been a<br class="">slow scrub up to that point probably won't make a massive or immediate<br class="">difference in the reported scrub rate. You should see it rising over<br class="">time, especially if you drastically speeded it up, but it's not any sort<br class="">of instant jump.<br class=""><br class="">(You can always monitor iostat, but that mixes in other pool IO. There's<br class="">probably something clever that can be done with DTrace.)<br class=""></blockquote>I've got some dtrace that will show progress. However, it is only marginally<br class="">useful when you've got multiple datasets.<br class=""><br class=""><blockquote type="cite" class="">This may already be obvious and well known to people, but I figured<br class="">I'd mention it just in case.<br class=""></blockquote>People fret about scrubs and resilvers, when they really shouldn't. In ZFS<br class="">accessing data also checks and does recovery, so anything they regularly<br class="">access will be unaffected by the subsequent scan. Over the years, I've tried<br class="">several ways to approach teaching people about failures and scrubs/resilvers,<br class="">but with limited success: some people just like to be afraid... Hollywood makes<br class="">a lot of money on them :-)<br class=""> -- richard<br class=""><br class=""><br class=""></blockquote>No… not afraid, but I actually do think, that I can judge whether or not I want to speed scrubs up and trade in some performance for that. As long as I can do that, I am fine with it. And the same applies for resilvers, I guess.</div></div></blockquote><div><br class=""></div><div>For current OmniOS the priority scheduler can be adjusted using mdb to change</div><div>the priority for scrubs vs other types of I/O. There is no userland interface. See Adam's</div><div>blog for more details.</div><div><a href="http://dtrace.org/blogs/ahl/2014/08/31/openzfs-tuning/" class="">http://dtrace.org/blogs/ahl/2014/08/31/openzfs-tuning/</a></div><div><br class=""></div><div>If you're running Solaris 11 or pre-2015 OmniOS, then the old write throttle is impossible</div><div>to control and you'll chase your tail trying to balance scrubs/resilvers against any other</div><div>workload. From a control theory perspective, it is unstable.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""> If you need to resilver one half of a mirrored zpool, most people will want that to run as fast as feasible, don't they?<br class=""></div></div></blockquote><div><br class=""></div><div>It depends. I've had customers on both sides of the fence and one customer for whom we</div><div>cron'ed the priority changes to match their peak. Suffice to say, nobody seems to want </div><div>resilvers to dominate real work.</div><div> -- richard</div></div><br class=""></body></html>