How Hot Spares Work

When I/O errors occur, Solaris Volume Manager searches the hot spare pool for a hot spare based on the order in which hot spares were added to the hot spare pool. Solaris Volume Manager checks the hot spare pool for the first available hot spare whose size is equal to or greater than the size of the slice that is being replaced. The first hot spare found by Solaris Volume Manager that is large enough is used as a replacement. Solaris Volume Manager changes the hot spare's status to “In-Use” and automatically resynchronizes the data if necessary. The order of hot spares in the hot spare pool is not changed when a replacement occurs.

In the case of a mirror, the hot spare is resynchronized with data from a functional submirror. In the case of a RAID-5 volume, the hot spare is resynchronized with the other slices in the volume. If a slice of adequate size is not found in the list of hot spares, the submirror or RAID-5 volume that failed goes into a failed state and the hot spares remain unused. In the case of the submirror, the submirror no longer replicates the data completely. In the case of the RAID-5 volume, data redundancy is no longer available.

When you add hot spares to a hot spare pool, add them from smallest to largest in size. This strategy avoids potentially wasting “large” hot spares as replacements for small slices.

When a slice experiences an I/O error, the failed slice is placed in the “Broken” state. To fix this condition, first repair or replace the failed slice. Then, bring the slice back to the “Available” state by using the Enhanced Storage tool within the Solaris Management Console. Or, use the metahs -e command.

A submirror or RAID-5 volume is uses a hot spare in place of a failed slice until that failed slice is enabled or replaced. The hot spare is then marked “Available” in the hot spare pool. This hot spare is again ready for use.