Peter C. Tribble wrote:
> In article <0001HW.BE22C8EA00096080F03055B0@news.diapason.com >,
> Georges Tomazi <gt@diapason.com> writes:
>
>>Hi -
>>
>>Last night I had a problem with a Solaris 9 server. A 67 Gb slice (on a 73 Gb
>>RAID-1 disk) failed and the slice was taken over by a hot spare. This
>>morning, metastat was showing the following :
>>
>># metastat d3
>
> ...
>
>>d33: Submirror of d3
>
> ...
>
>> Device Start Block Dbase State Reloc Hot Spare
>> c0t2d0s3 0 No Okay Yes c0t4d0s7
>
> ...
>
>
>>However, the disk seems to be OK (less than a year old). No bad blocks and
>>the others slices on it are just fine.
>
>
> So why did disksuite fail it? It must have had some reason for doing so
> that is likely to be logged somewhere. Disksuite is pretty aggressive
> at failing devices (it dosn't allow many errors before chucking it out
> completely) but I've always seen at least one error that explains it.
>
> I usuall (in the cases where the disk is responsive at all) do a
> format/analyze/read/repair and try replacing it just to see if it was a
> single bad block. Sometimes works.
>
>
>>So before physically replacing it, I'd
>>like to put back the submirror on it and see how it goes. If it fails again
>>I'll replace it.
>>
>>I'm just not 100% sure how to enable again the mirror. It would be great if
>>someone could confirm if that's the right way to do it:
>>
>># metadetach d3 d33 (detaching the failed submirror)
>># metaclear d33 (clearing it)
>># metainit d33 1 1 c0t2d0s3 -h hsp000 (creating the submirror and allocating
>>again the hot spare pool)
>># metattach d3 d33 (attaching and synchronizing the submirror)
>
>
> Seems complicated. How about just
>
> metareplace -e d3 c0t2d0s3
>
>
>>I'm not sure about the third step. In Sun's documentation, they suggest a
>>command like "metainit d33 2 1 c0t2d0s3 1 c0t3d0s3".
>
>
> That's a concatenation. Don't think you want that...
>
>
>>I'm concerned about the risk of loosing the data on the working submirror
>>(c0t3d0s3)...
>>
>>After enabling again the submirror, the hot spare should be automatically
>>released, right ?
>
>
> If the metareplace succeeds. And if the metareplace fails, the hot
> spare should still be in place.
>

It should be in the messages file.