From owner-freebsd-hardware@FreeBSD.ORG Tue Oct 19 13:16:17 2010 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 175411065780; Tue, 19 Oct 2010 13:16:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C8B1F8FC1E; Tue, 19 Oct 2010 13:16:16 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 7C3FE46B2C; Tue, 19 Oct 2010 09:16:16 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id AB0778A029; Tue, 19 Oct 2010 09:16:14 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 19 Oct 2010 08:49:58 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4CB8A614.6000707@greatbaysoftware.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201010190849.58660.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 19 Oct 2010 09:16:14 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Charles Owens , Sergey Kandaurov , Scott Long , freebsd-hardware@freebsd.org Subject: Re: mfiutil reports "PSTATE 0x0020" new drive state X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 13:16:17 -0000 On Monday, October 18, 2010 12:55:18 pm Sergey Kandaurov wrote: > On 16 October 2010 02:18, Sergey Kandaurov wrote: > > On 16 October 2010 00:51, Charles Owens wrote: > >> Hmm... the problem appears to have resolved itself. After a few hours the > >> new drive seems to have gone back into the array, and the original hot spare > >> drive put back into hot-spare state. > >> > >> So I'm interpreting state 0x0020 to therefore mean something like "hang on > >> while I use this new drive to automatically put everything back as it was > >> before the failure". Is this correct? > >> > >> Thanks, > >> Charles > >> > >> [root@Bsvr ~]# mfiutil show drives > >> mfi0 Physical Drives: > >> ( 149G) ONLINE SATA enclosure 1, slot 0 > >> ( 149G) ONLINE SATA enclosure 1, slot 1 > >> ( 149G) ONLINE SATA enclosure 1, slot 2 > >> ( 149G) HOT SPARE SATA enclosure 1, slot > >> 3 > >> ( 149G) ONLINE SATA enclosure 1, slot 4 > >> > >> > > >>> > [...] > >>> [root@svr ~]# mfiutil show drives > >>> mfi0 Physical Drives: > >>> ( 149G) ONLINE SATA enclosure 1, slot > >>> 0 > >>> ( 149G) ONLINE SATA enclosure 1, slot > >>> 1 > >>> ( 149G) ONLINE SATA enclosure 1, slot > >>> 2 > >>> ( 149G) ONLINE SATA enclosure 1, slot > >>> 3 > >>> ( 149G) PSTATE 0x0020 SATA enclosure > >>> 1, slot 4 > >>> > >>> mfi0: port 0x1000-0x10ff mem > >>> ... > >>> > > > > Hi, Charles Owens. > > > > 0x20 is much likely to be the copyback physical state, > > which is missing in enum mfi_pd_state. > > And what you've experienced is copyback feature in action :) > > Your array has been rebuilt with HSP as its ordinal PD, then you > > switched failed drive > > with good one, and HSP came into copyback mode to move all its data back > > to good disk. That prevents reordering of disk numbers in array and > > double rebuilding. > > > > So, it no one objects, I'd like to commit this change. If you have access to the MFI docs (or a reference in the Linux driver, e.g.) then this is fine. The existing pd_state enum lists the values for PD state that were listed in the MFI docs I had access to at the time I wrote mfiutil. -- John Baldwin