Why Is RAID Capacity Still Unchanged After Replacing Every Drive?

RAID capacity usually stays unchanged because one layer in the storage stack still exposes the old boundary. Confirm that every replacement is an active, fully rebuilt member, then compare the reported size of the physical disks, member partitions, RAID device, volume layer, and mounted filesystem in that order. The first layer that still reports the old size is normally the layer that must be expanded.

Confirm That Every Replacement Became an Active Member

Start with the array state rather than the capacity screen. A larger disk that is still listed as a spare, replacement target, rebuilding device, or unavailable member does not yet increase the common size of the RAID group. Record the serial number, role, usable sector count, rebuild state, and error counters for every member before changing anything.

In a mirror, capacity normally cannot grow until all members that define the mirror are large enough. In parity RAID, every member that participates in the current geometry may also need to expose the larger component size. The safe replacement sequence is to replace one disk, wait for a clean rebuild, verify the array, and only then replace the next disk. ZimaSpace’s guide to replacing every mirror member one at a time explains why usable capacity often remains unchanged during the intermediate stages.

Find the First Storage Layer That Still Reports the Old Size

A NAS may stack several independent capacity limits: physical disk, partition table, RAID member, RAID device, encryption mapping, LVM physical volume, logical volume, storage pool, and filesystem. Replacing hardware changes only the first layer. Every layer above it must discover or be told about the larger boundary before the mounted share can use the extra space.

Write down the size shown at each layer instead of repeatedly pressing an “expand” button. The correct diagnosis is the first transition where a lower layer is larger but the next layer remains at the old size.

Check Whether the Replacement Partitions Still End at the Old Boundary

Many replacement workflows copy the original partition table so that RAID metadata begins at the same offset. That protects alignment and member identity, but it can also leave a large unused region after the old partition end. The physical disk is larger while the RAID member presented to the array is still the old size.

Compare sector counts rather than rounded terabyte labels. Drives sold with the same nominal capacity can have slightly different usable sector totals, and an undersized replacement partition can prevent the array from selecting a larger common component size. Do not recreate partitions casually on an active member; preserve the start sector, partition type, and RAID metadata layout, and make only the platform-supported change after a verified backup.

Verify That the RAID Layer Has Actually Been Grown

Healthy status and larger members do not prove that the RAID device itself has adopted the new geometry. Some storage systems expand automatically after the last replacement and rebuild; others require a separate array-level grow operation. In Linux md, for example, the RAID device still needs an explicit grow step after the underlying member devices expose the larger size.

Before starting a grow, confirm that the array is clean, every expected member is active, no rebuild or scrub is running, and recent logs contain no new read, write, timeout, or link errors. A grow operation changes geometry or component size; it should not be used to hide an unresolved degraded state.

Inspect Encryption, LVM, and Storage-Pool Boundaries Above RAID

If the RAID device is larger but the logical volume remains unchanged, the extra blocks are waiting in an intermediate layer. An encrypted mapping may need to rescan the larger device. An LVM physical volume may need to recognize new extents before the volume group can assign them, and the logical volume must be extended before the filesystem can grow.

Do not skip directly to the filesystem because a capacity tool reports free space “somewhere” in the stack. Verify the size presented by each mapping and volume object. In thin-provisioned or pooled systems, distinguish unallocated pool space from free space inside the mounted filesystem; they are not interchangeable.

Grow the Filesystem Only After Its Block Device Is Larger

A filesystem can use only the block range its underlying device currently presents. Ext4, XFS, Btrfs, ZFS, and other filesystems have different grow rules, mount-state requirements, and safety checks. Identify the filesystem and storage stack first, then use its supported procedure instead of borrowing a command from another platform.

ZFS is a useful example of why the final step can be implementation-specific. After all mirror members are replaced, a ZFS mirror may still need the new device size expanded before the pool exposes the space. Btrfs may likewise require the larger device boundary to be recognized even though replacement completed successfully. The correct action depends on which layer owns the member devices.

Stop When the Platform Cannot Expand the Existing Layout In Place

Some RAID controllers, appliance layouts, partition schemes, and filesystems cannot grow the current configuration in place. Others can expand only certain RAID levels or require all members to match exactly. If the management interface offers no supported grow path, do not force commands from a different storage stack merely because the disk sizes look similar.

Stop and plan a backup-and-recreate migration when member histories conflict, the array is degraded, health counters are rising, the partition layout cannot be changed safely, or the platform documents no in-place expansion method. After a supported grow, verify the new size at every layer, run the platform’s integrity check, confirm normal application access, and preserve the before-and-after status as the new baseline.