Table 28. Event descriptions and recommended actions (continued)
Number
Severity
Description/Recommended actions
●
To restore the disk group, use the CLI
dequarantine
command to dequarantine the disk
group. If more than one disk group is quarantined you must individually dequarantine each
disk group, whether it is fault tolerant or not. When dequarantine is complete, the disk group
will return to the state it was in before being quarantined. For example, if the disk group was
reconstructing before being quarantined, the disk group will resume reconstructing where it
stopped
●
For a linear disk group, if you want to find where parity is incorrect, use the CLI
scrub
vdisk
command with the
fix
parameter disabled. This step is optional and not required to
fix data integrity issues
●
For a fault tolerant disk group, run either
scrub disk-groups
for a virtual disk group or
scrub vdisk
with the
fix
parameter enabled for a linear disk group. This step will make
the parity consistent with the existing user data, and is required to fix data integrity issues.
●
For a reconstructing disk group, let reconstruction finish, then run either
scrub disk-
groups
for a virtual disk group or
scrub vdisk
with the
fix
parameter enabled for a
linear disk group. This step will make the parity consistent with the existing user data, and is
required to fix data integrity issues.
●
Restore the data to the disk group from a backup copy.
593
Info.
A PCIe bus has transitioned to a different speed.
Recommended actions:
●
No action is required.
594
Info.
The indicated disk in the indicated disk group is missing and the disk group is quarantined. While
the disk group is quarantined, in linear storage any attempt to access its volumes from a host will
fail. In virtual storage, all volumes in the pool will be forced read-only. If all of the disks become
accessible, the disk group will be dequarantined automatically with a resulting status of FTOL.
If not all of the disks become accessible but enough become accessible to allow reading from
and writing to the disk group, it will be dequarantined automatically with a resulting status of
FTDN or CRIT. If a spare disk is available, reconstruction will begin automatically. When the disk
group has been removed from quarantine, event 173 is logged. For a more detailed discussion of
dequarantine, see the PowerVault Manager or CLI documentation.
CAUTION:
●
Avoid using the manual dequarantine operation as a recovery method when
event 172 is logged because this causes data recovery to be more difficult or
impossible.
●
If you clear unwritten cache data while a disk group is quarantined or offline,
that data will be permanently lost.
Recommended actions:
●
If event 173 has subsequently been logged for the indicated disk group, no action is required.
The disk group has already been removed from quarantine.
●
Otherwise, perform the following actions:
○
Check that all enclosures are powered on.
○
Check that all disks and I/O modules in every enclosure are fully seated in their slots and
that their latches are locked.
○
Reseat any disks in the quarantined disk group that are reported as missing or failed in
the user interface. (Do NOT remove and reinsert disks that are not members of the disk
group that is quarantined.)
○
Check that the SAS expansion cables are connected between each enclosure in the
storage system and that they are fully seated. (Do NOT remove and reinsert the cables
because this can cause problems with additional disk groups.)
○
Check that no disks have been removed from the system unintentionally.
○
Check for other events that indicate faults in the system and follow the recommended
actions for those events. But, if the event indicates a failed disk and the recommended
action is to replace the disk, do NOT replace the disk at this time because it may be
needed later for data recovery.
Events and event messages
125
