On 19 October 2010 16:49, John Baldwin <jhb@freebsd.org> wrote:
quoted text
> 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.
>

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

-- 
wbr,
pluknet
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"