From owner-freebsd-fs@FreeBSD.ORG Sat Jun 9 14:31:20 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8A271065672 for ; Sat, 9 Jun 2012 14:31:20 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.freebsd.org (Postfix) with ESMTP id 381238FC15 for ; Sat, 9 Jun 2012 14:31:20 +0000 (UTC) Received: from peterlaptop.site (hmbg-4d06e8be.pool.mediaWays.net [77.6.232.190]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0Luaps-1RvTJ109eC-0102JF; Sat, 09 Jun 2012 16:31:19 +0200 Message-ID: <4FD35E14.2040408@brockmann-consult.de> Date: Sat, 09 Jun 2012 16:30:44 +0200 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120421 Thunderbird/12.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <5532CFFB-F943-4D9E-9722-7FB9C8A9F82A@ebureau.com> In-Reply-To: <5532CFFB-F943-4D9E-9722-7FB9C8A9F82A@ebureau.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:61gjGRFVJU/jN5XuWbV3zSAtavAEi7IzQQOJ/H2QcAP vekEqS8ZLLr+FGbQuesJVjASU/ZekuC6MrOIt6/8kiIq5ZjdZv ZUhHPchNOmFrwKlz2x9txK+Kvk2Sr/+w8Odtp17WGT619Szz1I t7LEOJMqrh7b2D+RJYsEug8t0P3Ntg7qSktreeZGl6AnwjQTOU 9oQnW/vEQ1pFbormHbfajaBgDxx1Hpb+SwV6PF7KgM21vUW0or XlM+/EICgCkRGn1eP7Es8dk8+sO9AYLdmZ2c3GCX+ZL+Bf1kTo izuNlCofNC17XEVXaToSAfU6aWJy3PGvMvHElSQh/hApGzG56B mFp7nJfD1ODzNdOKoerK+OxtvAIzXTHxSQ9r5Z+tDOf9xStpjd zXUVWVhNAVFGw== X-Mailman-Approved-At: Sat, 09 Jun 2012 15:11:22 +0000 Subject: Re: Can mps drop a failing device from bus? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 14:31:20 -0000 I think I've had the same issues, but resolved it by avoiding certain disks and firmware (for disks that aren't really failed... don't know if a failing disk will cause such problems in the future). Here is a related message list thread about it: http://lists.freebsd.org/pipermail/freebsd-fs/2012-January/013477.html On 06/05/2012 12:54 AM, Dustin Wenz wrote: > I asked this question back in April on the stable list with no response ( http://lists.freebsd.org/pipermail/freebsd-stable/2012-April/067305.html ). I've now been seeing the same behavior on 9.0-release, and I thought it would be good to ask again here. > > There is a failure mode for SATA disks (Seagate Barracuda ST3000DM001 disks, in this case) that the mps driver doesn't handle very well. If a disk is slow to respond, or is unresponsive altogether, I'd like it to be removed from the bus and degrade the zpool that it's a part of. > > The way things are now, mps will just report a lot of "SCSI command timeout on device" messages. Any I/O on the affected zpools will hang for an excessive amount of time (sometimes forever). We typically configure our storage volumes as a pool of mirrors, with the expectation that availability will be maintained if any redundant disk(s) should fail. Unfortunately, availability is actually made *worse* on highly-redundant mirrors when mps won't give up on an unresponsive device. > > It's possible that I'm overlooking an obvious solution, or some relevant configuration options for the driver. Can anyone offer some insight on this? > > Thanks, > > - .Dustin > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"