SysAdmin Blog, TechTips and Reviews

An (ex) System Administrator's Blog



Archives Posts

Solutions for Solaris SVM Needs Maintenance and Last Erred status

September 24th, 2010 by elizar

This post is because while patching a Solaris 10 server with patch level Generic_142900-02 to Generic_142900-13.. There’s a need maintenance error on one of the sub mirror:

When a slice in a mirror or RAID5 metadevice device experiences errors,
DiskSuite puts the slice in the “Maintenance” state. No further reads or
writes are performed to a slice in the “Maintenance” state. Subsequent
errors on other slices in the same metadevice are handled differently,
depending on the type of the metadevice.

A mirror may be able to tolerate many slices in the “Maintenance” state and still be read from and written to. A RAID5 metadevice, by definition, can only tolerate a single slice in the “Maintenance” state. When either a mirror or RAID5 metadevice has a slice in the “Last Erred” state, I/O is still attempted to the slice marked “Last Erred”. This is because a “Last Erred” slice contains the last good copy of data from DiskSuite’s point of view.

Read the rest of this entry »

Filed under Uncategorized having No Comments »

Archives Posts

Metastat Needs Maintenance Metareplace

November 15th, 2009 by elizar

Guilty! Putting all those Metastat keywords on one subject, that’s me! ANyway, I don’t want to stale this blog so once in a while I’m going to be posting some bits and pieces of Unix tools/tips.. and here’s a new one about SVM… Responding to Disk Errors courtesy of BigAdmin!

Read the rest of this entry »

Filed under Solaris, Solaris 10, Tips having No Comments »

Archives Posts

Replacing a Failed Disk in Solaris Mirror (SVM)

January 16th, 2009 by elizar

This one is about Solaris Volume Manager and all those meta commands you can think of.. (metadb, metadettach, metattach, metaclear etc)…

Yesterday we had to replace a failed disk that belongs to a mirror. The disk is running in a Sparc Solaris 10 box. It’s a 72GB from Fujitsu

c1t1d0           Soft Errors: 440 Hard Errors: 12 Transport Errors: 124
Vendor: FUJITSU  Product: MAY2073RCSUN72G  Revision: 0501 Serial No: 0711S0935R
Size: 73.40GB <73400057856 bytes>

As you can see from the iostat -En command, the disk is spitting hard errors and must be replaced before it can cause a lot more headache. It’s in c1t1, right.

Here’s what we’re supposed to do:

  • we could delete the meta data base that corresponds to the failed disk
  • detached the failed disk/slices to the mirror
  • clear it
  • unconfigure the disk
  • replace the disk
  • configure the disk
  • create new meta device database
  • Initialize the disk
  • Attached it to mirror
  • and sync

Here’s the detailed job:

Read the rest of this entry »

I was here...