Slowing down resilvering of ZFS

Quicksearch

Disclaimer

The individual owning this blog works for Oracle in Germany. The opinions expressed here are his own, are not necessarily reviewed in advance by anyone but the individual author, and neither Oracle nor any other party necessarily agrees with them.

Navigation

< About Java, parallel garbage collection and processor sets | Less known Solaris features: hxbt - or: WAN emulation >

Slowing down resilvering of ZFS

Wednesday, June 9. 2010

Most of the time you want your ZFS working as fast as possible, but there are occasions where you want to slow down thing a little bit not to disturb the real work too much. Resilvering or scrubing of a ZFS pool is such an example. A ZFS resilvering can be very resource hungry.

Now there is a mechanism to prevent the system from experiencing such a slowdown by reducing the speed of resilvering/scrubbing in favor of more important I/O . The code enabling Opensolaris to do so found its way to the source yesterday. The mechanism is relatively easy: Whenever there was a read or a sync write to an pool without seperate log in the last 50 timer ticks, there is an additional delay of 2(resilvering) or 4(scrubbing) ticks between the scan steps.

Posted by Joerg Moellenkamp in English, Oracle, Solaris at 09:09 | Comments (2) | Trackbacks (0)

View as PDF: This entry | This month | Full blog

Trackbacks

Trackback specific URI for this entry

No Trackbacks

Comments

Display comments as (Linear | Threaded)

That's a very welcome addition. Current resilvering is an absolute pain if the pool hosts iSCSI volumes.

BTW: Contrary to what some of the bug reports say, my experience is that resilvering is far more intrusive than scrubbing, at leas in combination with iSCSI volumes. To us, scrubbing during production work wasn't an issue, while resilvering was.

#1 Arnd Beißner on 2010-06-09 20:06 (Reply)

Ressource hungry is a very nice description.

From my experience production pools with a disk usage more than 85 percent is a real disaster no matter how big the pool is.Arnd its not only related to iScsi Volumes. We made this experience too on HDS 9990v Units.

The only possible solution for us was to keep the treshold under 85 percent. But Disk space is not really cheep.

#1.1 BerndH (Homepage) on 2010-06-09 23:23 (Reply)

Add Comment

Name
Email
Homepage
In reply to
Comment	E-Mail addresses will not be displayed and will only be used for E-Mail notifications. To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly. Enter the string from the spam-prevention image above: Standard emoticons like :-) and ;-) are converted to images. Enclosing asterisks marks text as bold (word), underscore are made via _word_.
	Remember Information? Subscribe to this entry