Re: mfiutil reports "PSTATE 0x0020" new drive state

On Tuesday, October 19, 2010 10:05:24 am Sergey Kandaurov wrote:
> On 19 October 2010 16:49, John Baldwin <jhb_at_freebsd.org> wrote:
> > On Monday, October 18, 2010 12:55:18 pm Sergey Kandaurov wrote:
> >> On 16 October 2010 02:18, Sergey Kandaurov <pluknet_at_gmail.com> wrote:
> >> > On 16 October 2010 00:51, Charles Owens <cowens_at_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_at_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_at_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.
> >
> 
> Hi, John.
> 
> I've no such access unfortunately.
> As for FreeBSD vendor's driver, it doesn't list PD states at all
> (and looks like their version lags behind other OS versions).
> 
> However,  they (LSI) are listing COPYBACK entry as 0x20 in its Linux driver,
> and there: http://lkml.org/lkml/2009/5/5/389

Ok.  You should add the SYSTEM state too (0x40) while you are at it.

-- 
John Baldwin