Hot spare pools are named hspnnn, where nnn is in the range 000-999.
You can create empty hot spare pools, enabling you to add hot spares when they become available.
Must a hot spare be a physical device?
Yes. It cannot be a metadevice.
When a slice in a submirror or RAID5 metadevice goes into the "errored" state, a slice from the associated hot spare pool is used to replace it. DiskSuite selects the first hot spare (slice) that is large enough to replace the errored slice.
DiskSuite searches a hot spare pool for a hot spare based on the order in which hot spares are added to a hot spare pool. The first hot spare found that is large enough is used as a replacement. When adding hot spares to a hot spare pool, it is best to add them from smallest to largest. This avoids potentially wasting "large" hot spares as replacements for small slices.
Hot spares must be equal to or greater than the smallest slice in the submirror or RAID5 metadevice with which the hot spare pool is associated. If DiskSuite cannot substitute an appropriately sized hot spare for a failed slice in a submirror or RAID5 metadevice, hot sparing will not occur for that metadevice.
No. Hot sparing can only be used for mirrors and RAID5 metadevices. A hot spare pool must be associated with a submirror or a RAID5 metadevice.
What should I do if no hot spares are marked as Available?
Some hot spares must be marked as Available. If all hot spares are marked In-Use, you should either add more hot spares to the hot spare pool or repair the spared slices and return them to service.
Do not assign a hot spare pool to a submirror in a one-way mirror. Failed slices in a one-way mirror cannot be replaced by a hot spare. In these metadevices, no other copy of data is available to reconstruct on the hot spare.
Why should hot spares be defined on different controllers?
To maximize their availability in case of controller errors or failures.