From owner-freebsd-fs@freebsd.org Wed Jul 8 14:27:59 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 98D2899658B for ; Wed, 8 Jul 2015 14:27:59 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 63F241077 for ; Wed, 8 Jul 2015 14:27:59 +0000 (UTC) (envelope-from mike@sentex.net) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.9/8.14.9) with ESMTP id t68ERwwW058738 for ; Wed, 8 Jul 2015 10:27:58 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <559D3380.8050703@sentex.net> Date: Wed, 08 Jul 2015 10:28:16 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: Speeding up resilvering References: <559D2AB6.5070007@FreeBSD.org> <559D2C7C.6060201@denninger.net> <559D3167.1000705@infracaninophile.co.uk> <559D3236.1060102@denninger.net> In-Reply-To: <559D3236.1060102@denninger.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.75 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 14:27:59 -0000 On 7/8/2015 10:22 AM, Karl Denninger wrote: >>> What OS version? >>> >> 10.1-RELEASE-p10 >> >> Cheers, >> >> Matthew > Look at the IO saturation on the disk channel(s) involved with either > systat -vm or iostat. If the channel is saturated then there's nothing > you can do in terms of tuning; the question then turns to why actual I/O > performance is so poor and has to be addressed there. I had one server that was taking ages, and it turned out to be the controller, not the disk that was hosed. As Karl suggested, take a look at the throughput on gstat. Is anyone disk or groups of disks lagging far behind on write speeds ? In my case, it was a very obvious and glaring outlier. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/