Date: Mon, 18 Oct 2010 10:25:42 -0700 From: Garrett Cooper <gcooper@FreeBSD.org> To: Sergey Kandaurov <pluknet@gmail.com> Cc: Charles Owens <cowens@greatbaysoftware.com>, FreeBSD Current <freebsd-current@freebsd.org>, Scott Long <scottl@freebsd.org>, freebsd-hardware@freebsd.org Subject: Re: mfiutil reports "PSTATE 0x0020" new drive state Message-ID: <AANLkTimC4RbgB_CUnqCqftV%2BiMMgp=P607BOgAmshytZ@mail.gmail.com> In-Reply-To: <AANLkTikzk6Pjr-mUx=m254JO3MdJXQw1zdTU12if0CGu@mail.gmail.com> References: <4CB8A614.6000707@greatbaysoftware.com> <4CB8BED6.8040204@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 Mon, Oct 18, 2010 at 9:55 AM, Sergey Kandaurov <pluknet@gmail.com> wrote=
:
> On 16 October 2010 02:18, Sergey Kandaurov <pluknet@gmail.com> wrote:
>> On 16 October 2010 00:51, Charles Owens <cowens@greatbaysoftware.com> wr=
ote:
>>> =A0Hmm... the problem appears to have resolved itself. =A0After a few h=
ours 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 w=
as
>>> before the failure". =A0Is this correct?
>>>
>>> Thanks,
>>> Charles
>>>
>>> [root@Bsvr ~]# mfiutil show drives
>>> mfi0 Physical Drives:
>>> ( =A0149G) ONLINE<ST9160511NS SN04 serial=3D9SM236JR> =A0SATA enclosure=
1, slot 0
>>> ( =A0149G) ONLINE<ST9160511NS SN04 serial=3D9SM237KF> =A0SATA enclosure=
1, slot 1
>>> ( =A0149G) ONLINE<ST9160511NS SN04 serial=3D9SM236N8> =A0SATA enclosure=
1, slot 2
>>> ( =A0149G) HOT SPARE<ST9160511NS SN04 serial=3D9SM237EK> =A0SATA enclos=
ure 1, slot
>>> 3
>>> ( =A0149G) ONLINE<ST9160511NS SN04 serial=3D9SM238AG> =A0SATA enclosure=
1, slot 4
>>>
>>>
>
>>>>
> [...]
>>>> [root@svr ~]# mfiutil show drives
>>>> mfi0 Physical Drives:
>>>> ( =A0149G) ONLINE<ST9160511NS SN04 serial=3D9SM236JR> =A0SATA enclosur=
e 1, slot
>>>> 0
>>>> ( =A0149G) ONLINE<ST9160511NS SN04 serial=3D9SM237KF> =A0SATA enclosur=
e 1, slot
>>>> 1
>>>> ( =A0149G) ONLINE<ST9160511NS SN04 serial=3D9SM236N8> =A0SATA enclosur=
e 1, slot
>>>> 2
>>>> ( =A0149G) ONLINE<ST9160511NS SN04 serial=3D9SM237EK> =A0SATA enclosur=
e 1, slot
>>>> 3
>>>> ( =A0149G) PSTATE 0x0020<ST9160511NS SN04 serial=3D9SM238AG> =A0SATA e=
nclosure
>>>> 1, slot 4
>>>>
>>>> mfi0:<LSI MegaSAS 1078> =A0port 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.
Check with LSI before you commit that; you might not understand
the overall nuances of that value.
Thanks,
-Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTimC4RbgB_CUnqCqftV%2BiMMgp=P607BOgAmshytZ>