Growing a RAID Array: What You Need to Know



  • A common question that I see asked is if a RAID array can be grown or expanded. This is a rather complex question because the answer cannot be determined by the RAID level, or at least not the RAID level alone, as no RAID level specifies the ability to or the manner in which an increase in capacity should occur. RAID expansion processes are purely a proprietary aspect of a specific RAID implementation. So to even begin looking at this capability we have to know the exact RAID implementation as the most important factor. This implementation would be either the exact hardware RAID model and firmware (with as the Dell PERC 6/i or the HP SmartArray P420) or the software RAID information such as ZFS RAIDZ 2, or Linux MD.

    Once we know the implementation of the RAID, we also need to know the RAID level. This is because, in many cases, expansion options depend on the RAID level. It is relatively common for hardware RAID to support expansion in parity RAID scenarios but not in non-parity scenarios because the parity process can often be reversed to grow an array relatively easily but other growth devices are more difficult to implement.

    In many cases with hardware RAID we would also need to determine the configuration of the hardware RAID. Almost no hardware RAID implementation supports any style of growth with any RAID level unless a certain amount of controller cache is available. So knowing the physical configuration is often mandatory to determine array growth options.

    Because array growth is very unique to each controller, configuration, RAID level and firmware update (often growth options are added later in a controller's lifecycle) a significant amount of information and subsequent research must often be done. If firmware on a device can be updated, this can alleviate many aspects of additional research by allowing research to include only the current specifications of a device and not historical ones as well.

    Once this information is gathered, we need to consider that there are two types of array growth:

    • Replacement of existing drives with larger drives. (E.g. removing 1TB drives and replacing with 2TB drives.)
    • Addition of drives to increase the spindle count in the array. (E.g. going from six drives to eight drives in the array.)

    Any given RAID implementation that does support array growth may only support one type or the other, although supporting both or neither is most common, and each type may need to be determined individually (only certain RAID levels, cache sizes, etc.)

    With all of this information we can be prepared to tackle the question of whether or not a specific RAID expansion option will exist for a unique scenario. With modern RAID implementations growth options are now becoming abundant whereas in the past it was relatively rare to have any options for growing a RAID array.

    Caveats

    • Parity Array Growth Failure: Growing a parity based array through the addition of new drives almost certainly will involve a state of induced failure where an existing array is put into a state as if one drive has failed and grown to include the new drive(s) by performing a full resilvering of the array. The array will see this no differently than if the array had previously been of the larger size and had experienced a drive failure. This can induce risks such as fragility concerning additional drives or the risk of encountering a URE during the resilver process. Growing a parity array in this manner should be considered very risky and while it can be performed while online one must consider the event of array loss to be far higher than usual and precautions, such as preemptive green zones and careful backups, should be taken.
    • Array Growth is not filesystem growth: Many people when growing a RAID array assume that this will equate, automatically, to the growth of systems utilizing the array. This is not the case. RAID array expansion only changes the size of the underlying block device. All layers of block storage abstraction sitting on top of the array will need to be adjusted as needed to utilize this additional storage. There is no way for the systems utilizing the array to know how the growth is intended to be used so this could not be automated, even if it was desired. For example additional partitions may be created or additional virtual disks, existing VDs or partitions might need to be expanded, on top of those logical volumes will likely need to be adjusted and only then would file systems potentially be grown.