Dell EMC ME4 Series - Page 118

Number Severity Description/Recommended actions
If the last global spare has been deleted or used for reconstruction, ALL disk groups that do not have at least
one dedicated or global spare are at increased risk. Note that even though there may be global spares still
available, they cannot be used for reconstruction of a disk group if that disk group uses larger-capacity disks
or a dierent type of disk. Therefore, this event may be logged even when there are unused global spares. If
the dynamic spares feature is enabled, this event will be logged even if there is an available disk that may be
used for reconstruction.
Recommended actions:
• Congure disks as dedicated spares or global spares.
– For a dedicated spare, the disk must be of the same type as the other disks in the linear disk group and
at least as large as the smallest-capacity disk in the linear disk group, and it should have the same or
better performance.
– For a global spare, it is best to choose a disk that is as big as or bigger than the largest disk of its type
in the system and of equal or greater performance. If the system contains a mix of disk types (SSD,
enterprise SAS, or midline SAS), there should be at least one global spare of each type (unless
dedicated spares are used to protect every disk group of a given type, which will only apply to a linear
storage conguration).
485 Warning The indicated disk group was quarantined to prevent writing invalid data that may exist in the controller that
logged this event.
This event is logged to report that the indicated disk group has been put in the quarantined oine state
(status of QTOF) to prevent loss of data. The controller that logged this event has detected (using information
saved in the disk group metadata) that it may contain outdated data that should not be written to the disk
group. Data may be lost if you do not follow the recommended actions carefully. This situation is typically
caused by removal of a controller module without shutting it down rst, then inserting a dierent controller
module in its place. To avoid having this problem occur in the future, always shut down the Storage Controller
in a controller module before removing it. This situation may also be caused by failure of the CompactFlash
card, as indicated by event 204.
Recommended actions:
• If event 204 is logged, follow the recommended actions for event 204.
• If event 204 is NOT logged, perform the following recommended actions:
– If event 486 is not logged at approximately the same time as event 485, reinsert the removed
controller module, shut it down, then remove it again.
– If events 485 and 486 are both logged at approximately the same time, wait at least 5 minutes for the
automatic recovery process to complete. Then sign in and conrm that both controller modules are
operational. (You can determine if the controllers are operational with the CLI show controllers
command or with the SMC.) In most cases, the system will come back up and no further action is
required. If both controller modules do not become operational in 5 minutes, data may have been lost.
If both controllers are not operational, follow this recovery process:
◦ Remove the controller module that rst logged event 486.
◦ Turn o the power for the controller enclosure, wait a few seconds, then turn it back on.
◦ Wait for the controller module to restart, then sign in again.
◦ Check the status of the disk groups. If any of the disk groups have a status of quarantined oine
(QTOF), dequarantine those disk groups.
◦ Reinsert the previously removed controller module. It should now restart successfully
486
Warning A recovery process was initiated to prevent writing invalid data that may exist in the controller that logged this
event.
The controller that logged this event has detected (using information saved in the disk group metadata) that it
may contain outdated data that should not be written to the disk groups. The controller will log this event,
restart the partner controller, wait 10 seconds, then kill itself. The partner controller will then unkill this
controller and mirror the correct cache data to it. This procedure will, in most cases, allow all data to be
correctly written without any loss of data and without writing any outdated data.
Recommended actions:
118 Events and event messages