mfiutil reports "PSTATE 0x0020" new drive state

[Sergey Kandaurov]

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.

-- 
wbr,
pluknet
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mfi.diff
Type: application/octet-stream
Size: 823 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20101018/fa3f77d1/mfi.obj