Event descriptions 9
• Reconstruction of a disk group failed. The indicated disk was being used as the target disk for reconstructing the
indicated disk group. While the disk group was reconstructing, another disk in the disk group failed and the status of
the disk group went to OFFL (offline). The indicated disk has a status of LEFTOVR (leftover).
• An SSD that was part of a disk group has reported that it has no life remaining. The indicated disk in the indicated
disk group failed and the disk group probably has a status of FTDN (fault tolerant with a down disk), CRIT (critical),
or OFFL (offline), depending on the RAID level and the number of disks that failed. If a spare is present and the disk
group is not offline, the controller automatically uses the spare to reconstruct the disk group. Subsequent events
indicate the changes that happen to the disk group. When the problem is resolved, event 9 is logged.
Recommended actions
• If a disk that was part of a disk group is down:
If the indicated disk failed for one of these reasons—excessive media errors, imminent disk failure, possible
hardware failure, disk is not supported, too many controller-recoverable errors, illegal request, due to being
degraded, or due to being too slow—replace the disk with one of the same type (SSD, enterprise SAS, or midline
SAS) and the same or greater capacity. For continued optimum I/O performance, the replacement disk should
have performance that is the same as or better than the one it is replacing.
If the indicated disk failed because a user forced the disk out of the disk group, RAID-6 initialization failed, or for
an unknown reason:
– If the associated disk group is offline or quarantined, contact technical support.
– Otherwise, clear the disk’s metadata to reuse the disk.
If the indicated disk failed because a previously detected disk is no longer present:
– Reinsert the disk or insert a replacement disk of the same type (SSD, enterprise SAS, or midline SAS) and the
same or greater capacity as the one that was in the slot. For continued optimum I/O performance, the
replacement disk should have performance that is the same as or better than the one it is replacing.
– If the disk then has a status of leftover (LEFTOVR), clear the metadata to reuse the disk.
– If the associated disk group is offline or quarantined, contact technical support.
• If reconstruction of a disk group failed:
If the associated disk group is online, clear the indicated disk's metadata so that the disk can be re-used.
If the associated disk group is offline, the CLI
trust
command may be able to recover some or all of the data in
the disk group. However, trusting a partially reconstructed disk may lead to data corruption. See the CLI help for
the
trust
command. Contact technical support for help to determine if the trust operation applies to your
situation and for help to perform it.
If the associated disk group is offline and you do not want to use the
trust
command, perform these steps:
– Delete the disk group (CLI
remove disk-groups
command).
– Clear the indicated disk’s metadata so the disk can be re-used (CLI
clear disk-metadata
command).
– Replace the failed disk or disks. (Look for other instances of event 8 in the event log to determine which disks
failed.)
– Re-create the disk group (CLI
add disk-group
command).
• If an SSD that was part of a disk group has reported that it has no life remaining, replace the disk with one of the
same type and the same or greater capacity. For continued optimum I/O performance, the replacement disk should
have performance that is the same as or better than the one it is replacing.
9
Info. The indicated spare disk has been used in the indicated disk group to bring it back to a fault-tolerant status.
Disk group reconstruction starts automatically. This event indicates that a problem reported by event 8 is resolved.
Recommended actions
• No action is required.