10/23/2020 Document 1010479.

1
Copyright (c) 2020, Oracle. All rights reserved. Oracle Confidential.

Solaris Volume Manager (SVM) metastat Command Shows Soft Partition in Errored State (Doc
ID 1010479.1)

APPLIES TO:

Solstice DiskSuite Software - Version 4.2.1 to 4.2.1 [Release 4.0]

Sun Solaris Volume Manager (SVM) - Version 11.9.0 to 11.11 [Release 11.0]
Oracle Solaris on SPARC (64-bit)
Oracle Solaris on SPARC (32-bit)
Oracle Solaris on x86-64 (64-bit)
Oracle Solaris on x86 (32-bit)

SYMPTOMS

In the following example, all access to application data is failing. The data set resides on a device managed by the soft
partitioning feature of Solaris Volume Manager (SVM). Everything is failing with an I/O error.

# df -k /data-84
df: (/data-84) not a block device, directory or mounted resource

# cp /database /data-84
cp: cannot create /data-84: I/O error

When you look at underlying device with metastat, you will discover a layered metadevice. d84 is a soft partition created
from d80 which in turn is created from disk slice c0t12d0s0. This creation technique is not in line with best practices in
Document 1417827.1 Solaris Volume Manager (SVM): Best Practices for Creation and Implementation of Soft Partitions
but none the less allowed. (d84 could be created directly from c0t12d0s0). This adds an extra layer of complexity to the
problem at hand.

# metastat
d84: Soft Partition
Device: d80
State: Errored
Size: 8388608 blocks (4.0 GB)
Extent Start Block Block count
0 32 8388608

d80: Concat/Stripe
Size: 17465344 blocks (8.3 GB)
Stripe 0:
Device Start Block Dbase State Reloc Hot Spare
c0t12d0s0 0 No Okay Yes

CHANGES

CAUSE

The origin or the problem is unclear. The errored state of the soft partition only lets us know that, at some point in time,
I/O to the soft partition failed. It may have been introduced by a previous crash, reboot, disk replacement, etc..

The /var/adm/messages file should be examined to confirm there is no associated hardware problem with any component
that the soft partition is comprised of. If there is, repairs need to be made at the hardware layer first. You can only

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=82skjboz1_217&id=1010479.1 1/3
10/23/2020 Document 1010479.1

continue with this procedure if appropriate redundancy is in place. Some typical SVM messages may look like:

[ID 616219 kern.warning] WARNING: Please umount(1M) /data-84 and run fsck(1M)

md_sp: [ID 641072 kern.warning] WARNING: md: d84 : write error on /dev/md/dsk/d80

SOLUTION

With some multi layered soft partitions (such as mirrored, soft partitions), you will still have access to data. However, you
will typically need to toggle the state from "Errored" to "Okay" before I/O can continue. A quick I/O test to the underlying
data set will let you know. Utilities such as iostat may also be used to measure activity.

The metarecover command lets us know that the extent header on the disk is indeed correct, and that it matches the
extent information in the replica.

Note: metarecover is run against the device the soft partition is created from! In this case, that's d80, (not c0t12d0s0).

# metarecover -n d80 -p
d80: Soft Partition metadb configuration is valid
d80: Soft Partition metadb matches extent header configuration

You can now rewrite the information from the replica to the disk. Rewriting the information will toggle the state back to
"Okay."

# metarecover d80 -p -m
d80: Soft Partition metadb configuration is valid

WARNING: You are about to overwrite portions of d80

with soft partition metadata. The extent headers will be
written to match the existing metadb configuration. If
the device was not previously setup with this
configuration, data loss may result.

Are you sure you want to do this (yes/no)? yes

d80: Soft Partitions recovered from metadb

# metastat
d84: Soft Partition
Device: d80
State: Okay
Size: 8388608 blocks (4.0 GB)
Extent Start Block Block count
0 32 8388608

d80: Concat/Stripe
Size: 17465344 blocks (8.3 GB)
Stripe 0:
Device Start Block Dbase State Reloc Hot Spare
c0t12d0s0 0 No Okay Yes

A subsequent file system check, or remount may be required to gain access again.

# umount /data-84
# mount /dev/md/dsk/d84 /data-84
# ls /data-84

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=82skjboz1_217&id=1010479.1 2/3
10/23/2020 Document 1010479.1

You can also recover this device by using the recovery techniques described in
Document 1005760.1 Solaris Volume Manager (SVM): How To Re-create An SVM Configuration Without Restoring
Data.

Still have questions? Consider posting them in the Oracle Solaris Volume Manager Community.

REFERENCES

NOTE:1417827.1 - Solaris Volume Manager (SVM): Best Practices for Creation and Implementation of Soft Partitions
NOTE:1005760.1 - Solaris Volume Manager (SVM) How To Re-create An SVM Configuration Without Restoring Data
Didn't find what you are looking for?

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=82skjboz1_217&id=1010479.1 3/3