What Should You Check When RAID Capacity Does Not Grow After Drive Replacement?

RAID capacity usually stays unchanged because one layer still reports the old boundary. Confirm the rebuild, member sizes, array geometry, partitioning, and filesystem in that order.

Replacing disks is only the hardware step. A NAS can contain several stacked size limits, and each one must expose the larger boundary before the next layer can use it. The safest diagnosis starts with read-only status checks, identifies the first layer that is still small, and grows only that layer instead of repeating the replacement.

Confirm Every Replacement Is Fully Integrated

Capacity cannot increase while a mirror or parity group still contains an original smaller member, a spare that has not become active, or a replacement that is still rebuilding. The array normally uses only the common capacity available across the members that define its geometry.

A disk can appear in the NAS inventory without being an in-sync member. Compare the array status, rebuild state, member role, serial number, and reported device size rather than assuming that a detected disk has completed the replacement process.

Wait for every required replacement and resilver or rebuild to finish without new errors. If one member is missing, faulted, or smaller than expected, resolve that condition before attempting any grow command because the array layer still has a valid reason to preserve the old size.

Check the Usable Size of Each Member Device

A larger physical drive may still present an old-size partition or recorded component boundary to RAID. Compare whole-disk capacity, partition end sectors, and the exact block devices listed as array members.

A larger version 1.x member can retain its recorded component boundary even after the physical disk has been replaced. Expanding to the maximum component size only after all active members can support it.

Do not recreate a partition merely because its displayed size is old. First record the starting sector, partition type, RAID UUID, and member serials; then use the platform-supported expansion method that preserves the existing start position and metadata.

Verify That the RAID Layer Has Been Expanded

When every member is larger but the RAID block device is not, the array geometry has not been expanded. The required action depends on whether the stack is md RAID, ZFS, Btrfs, a hardware controller, or a NAS-managed storage pool.

For md RAID, changing the active component size starts a resync of the newly exposed region. In a ZFS mirror, space becomes available only after every device in the mirror group has been replaced, and expansion may require autoexpand or an explicit online expansion.

Use the management interface or command that belongs to the actual RAID implementation. Stop if the array reports a reshape, degraded state, unsupported layout change, or member-size mismatch; those states need resolution before the new boundary can be trusted.

Check for a Partition or Volume Layer Above RAID

Even after the RAID device grows, a partition table, LVM physical volume, logical volume, encrypted mapping, or storage-pool allocation may still end at the previous sector. The filesystem cannot see blocks that an intermediate layer has not assigned to it.

Trace the mounted path downward with the platform’s block-device view and compare sizes at each hop. The first object that remains small is the layer to expand; changing a higher layer first will either fail or leave the new space unallocated.

Grow one boundary at a time and recheck the next layer before continuing. This staged method creates a clear rollback point and prevents a command intended for a filesystem from being applied to a RAID member or partition by mistake.

Grow the Filesystem Only After the Block Device Grows

A filesystem does not necessarily expand when its underlying RAID device becomes larger. Confirm that the mounted filesystem still reports the old size while its containing block device now reports the new size.

For ext2, ext3, and ext4, the filesystem resizer expects the partition or logical device to be enlarged first. XFS follows the same layer order, and an XFS growth operation expands a mounted filesystem into capacity already exposed by the device.

Use the filesystem-specific grow operation only after checking the device path, mount point, supported online state, and recent backup. A successful RAID expansion with an unchanged filesystem is incomplete, but it is safer than guessing at the wrong layer.

Account for Filesystem-Specific Device Resizing

Some filesystems manage multiple devices directly, so their replacement and resize steps do not match a conventional RAID-plus-filesystem stack. Btrfs is the common example: replacing a device and exposing its full new capacity are separate operations.

Replacing a Btrfs device with a larger target does not automatically expose the added blocks to the filesystem. A separate device resize explains why the replacement can complete cleanly while reported capacity remains unchanged.

Identify whether the filesystem itself owns the device set before using mdadm, partition, or LVM instructions. Mixing procedures from different storage stacks is one of the fastest ways to turn a simple capacity issue into a metadata problem.

Use a Layer-by-Layer Capacity Check

The decisive test is to write down the reported size at every layer from physical disk to mounted filesystem. Capacity should increase monotonically through the stack, with expected reductions for RAID redundancy, metadata, reserved blocks, and unit conversion.

If the physical disks are larger but the member partitions are not, fix the partition layer. If the RAID device is larger but the logical volume is not, extend the volume. If every block layer is larger but the mounted filesystem is not, perform the filesystem grow step.

Stop when two adjacent layers disagree in a way you cannot explain or when any health counter rises during expansion. Preserve status output and backups before changing geometry, because the first unexplained boundary is a diagnostic clue rather than a reason to force the next operation.