HP MSA 1040 HP MSA Events Description Reference Guide (762785-001, March 2014) - Page 57

If event 204 is NOT logged, perform the following recommended actions

Get HP MSA 1040 PDF manuals and user guides View all HP MSA 1040 manuals
Add to My Manuals
Save this manual to your list of manuals

Page 57 highlights

484 Warning No compatible spares are available to reconstruct this vdisk if it experiences a disk failure. Only vdisks that have dedicated spares will start reconstruction automatically. This situation puts data at increased risk because it will require user action to configure a disk as a dedicated or global spare before reconstruction can begin on the indicated vdisk if a disk in that vdisk fails in the future. If the last global spare has been deleted or used for reconstruction, ALL vdisks that do not have at least one dedicated spare are at increased risk. Note that even though there may be global spares still available, they cannot be used for reconstruction of a vdisk if that vdisk uses larger-capacity disks or a different type of disk; so 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 • Configure 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 vdisk and at least as large and 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 (SAS 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 vdisk of a given type). 485 Warning The indicated vdisk 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 vdisk has been put in the quarantined offline state (status of QTOF) to prevent loss of data. The controller that logged this event has detected (via information saved in the vdisk metadata) that it may contain outdated data that should not be written to the vdisk. 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 first, then inserting a different 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 confirm that both controller modules are operational. (You can determine if the controllers are operational with the show controllers CLI command or with the SMU.) 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 first logged event 486. • Turn off 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 vdisks. If any of the vdisks have a status of quarantined offline (QTOF), dequarantine those vdisks. • Reinsert the previously removed controller module. It should now restart successfully. Event descriptions 57

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
Event descriptions
57
484
Warning
No compatible spares are available to reconstruct this vdisk if it experiences a disk failure. Only vdisks
that have dedicated spares will start reconstruction automatically.
This situation puts data at increased risk because it will require user action to configure a disk as a
dedicated or global spare before reconstruction can begin on the indicated vdisk if a disk in that vdisk
fails in the future.
If the last global spare has been deleted or used for reconstruction, ALL vdisks that do not have at least
one dedicated spare are at increased risk. Note that even though there may be global spares still
available, they cannot be used for reconstruction of a vdisk if that vdisk uses larger-capacity disks or a
different type of disk; so 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
•
Configure 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 vdisk and at least
as large and 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
(SAS 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 vdisk of a given type).
485
Warning
The indicated vdisk 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 vdisk has been put in the quarantined offline state (status
of QTOF) to prevent loss of data. The controller that logged this event has detected (via information saved
in the vdisk metadata) that it may contain outdated data that should not be written to the vdisk. 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 first, then inserting a different 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 confirm that both controller modules
are operational. (You can determine if the controllers are operational with the
show
controllers
CLI command or with the SMU.) 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 first logged event 486.
•
Turn off 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 vdisks. If any of the vdisks have a status of quarantined offline (QTOF),
dequarantine those vdisks.
•
Reinsert the previously removed controller module. It should now restart successfully.