Date: Tue, 19 Oct 2010 08:49:58 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-current@freebsd.org Cc: Charles Owens <cowens@greatbaysoftware.com>, Sergey Kandaurov <pluknet@gmail.com>, Scott Long <scottl@freebsd.org>, freebsd-hardware@freebsd.org Subject: Re: mfiutil reports "PSTATE 0x0020" new drive state Message-ID: <201010190849.58660.jhb@freebsd.org> In-Reply-To: <AANLkTikzk6Pjr-mUx=m254JO3MdJXQw1zdTU12if0CGu@mail.gmail.com> References: <4CB8A614.6000707@greatbaysoftware.com> <AANLkTimYU_XmZ_DRjA_zJ7dcmgaj47UM6Tf3ea50cZLK@mail.gmail.com> <AANLkTikzk6Pjr-mUx=m254JO3MdJXQw1zdTU12if0CGu@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, October 18, 2010 12:55:18 pm Sergey Kandaurov wrote: > On 16 October 2010 02:18, Sergey Kandaurov <pluknet@gmail.com> wrote: > > On 16 October 2010 00:51, Charles Owens <cowens@greatbaysoftware.com> 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<ST9160511NS SN04 serial=9SM236JR> SATA enclosure 1, slot 0 > >> ( 149G) ONLINE<ST9160511NS SN04 serial=9SM237KF> SATA enclosure 1, slot 1 > >> ( 149G) ONLINE<ST9160511NS SN04 serial=9SM236N8> SATA enclosure 1, slot 2 > >> ( 149G) HOT SPARE<ST9160511NS SN04 serial=9SM237EK> SATA enclosure 1, slot > >> 3 > >> ( 149G) ONLINE<ST9160511NS SN04 serial=9SM238AG> SATA enclosure 1, slot 4 > >> > >> > > >>> > [...] > >>> [root@svr ~]# mfiutil show drives > >>> mfi0 Physical Drives: > >>> ( 149G) ONLINE<ST9160511NS SN04 serial=9SM236JR> SATA enclosure 1, slot > >>> 0 > >>> ( 149G) ONLINE<ST9160511NS SN04 serial=9SM237KF> SATA enclosure 1, slot > >>> 1 > >>> ( 149G) ONLINE<ST9160511NS SN04 serial=9SM236N8> SATA enclosure 1, slot > >>> 2 > >>> ( 149G) ONLINE<ST9160511NS SN04 serial=9SM237EK> SATA enclosure 1, slot > >>> 3 > >>> ( 149G) PSTATE 0x0020<ST9160511NS SN04 serial=9SM238AG> SATA enclosure > >>> 1, slot 4 > >>> > >>> mfi0:<LSI MegaSAS 1078> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201010190849.58660.jhb>