Date: Mon, 18 Oct 2010 20:55:18 +0400 From: Sergey Kandaurov <pluknet@gmail.com> To: Charles Owens <cowens@greatbaysoftware.com> Cc: 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: <AANLkTikzk6Pjr-mUx=m254JO3MdJXQw1zdTU12if0CGu@mail.gmail.com> In-Reply-To: <AANLkTimYU_XmZ_DRjA_zJ7dcmgaj47UM6Tf3ea50cZLK@mail.gmail.com> References: <4CB8A614.6000707@greatbaysoftware.com> <4CB8BED6.8040204@greatbaysoftware.com> <AANLkTimYU_XmZ_DRjA_zJ7dcmgaj47UM6Tf3ea50cZLK@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
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.
--
wbr,
pluknet
[-- Attachment #2 --]
Index: sys/dev/mfi/mfireg.h
===================================================================
--- sys/dev/mfi/mfireg.h (revision 214025)
+++ sys/dev/mfi/mfireg.h (working copy)
@@ -975,7 +975,8 @@
MFI_PD_STATE_OFFLINE = 0x10,
MFI_PD_STATE_FAILED = 0x11,
MFI_PD_STATE_REBUILD = 0x14,
- MFI_PD_STATE_ONLINE = 0x18
+ MFI_PD_STATE_ONLINE = 0x18,
+ MFI_PD_STATE_COPYBACK = 0x20
};
union mfi_ld_ref {
Index: usr.sbin/mfiutil/mfi_drive.c
===================================================================
--- usr.sbin/mfiutil/mfi_drive.c (revision 214025)
+++ usr.sbin/mfiutil/mfi_drive.c (working copy)
@@ -65,6 +65,8 @@
return ("REBUILD");
case MFI_PD_STATE_ONLINE:
return ("ONLINE");
+ case MFI_PD_STATE_COPYBACK:
+ return ("COPYBACK");
default:
sprintf(buf, "PSTATE 0x%04x", state);
return (buf);
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTikzk6Pjr-mUx=m254JO3MdJXQw1zdTU12if0CGu>