The source proves that replacing both RAID 1 members with larger disks does not automatically grow the usable filesystem. A user successfully replaced two 500 GB disks with 1 TB disks one at a time and let ZimaOS rebuild after each swap. At that point both physical members were 1 TB, but the RAID/device and Btrfs filesystem still exposed only the old 500 GB capacity.
On ZimaOS+ 1.5.4, that user then completed the expansion from SSH with mdadm --grow /dev/md0 --size=max, waited for the resulting recovery/resync, and finally ran btrfs filesystem resize max against the mounted filesystem. They reported that the GUI and df then showed the larger capacity. This is strong community verification, but it is still a manual CLI workflow—not a current IceWhale GUI procedure.
Back Up Before Starting a Capacity Expansion
RAID 1 protects against one member failure; it does not protect against operator mistakes, array metadata damage, filesystem mistakes, or a second disk problem during rebuild.
Replace Only One RAID Member at a Time
- power down;
- replace the first old disk with the larger disk;
- boot;
- use ZimaOS Recovery to rebuild;
- wait until recovery is completely finished.
Repeat for the Second Member
Only after the first rebuild completed did the user power down and replace the second disk, then run the GUI recovery again and wait for full completion.
At this stage the array was healthy on two larger physical devices but still sized to the historical member size.
The Community User Then Grew the mdadm Array
The source command was:
sudo mdadm --grow /dev/md0 --size=maxThey verified the new array geometry with mdadm --detail and waited for the new recovery/resync state to complete.
Never assume your array is /dev/md0; identify the actual array first.
Then the Btrfs Filesystem Had to Be Expanded
The source finished with:
sudo btrfs filesystem resize max /your/mounted/filesystemUse the real mounted Btrfs path rather than copying the placeholder literally.
Why Two Resize Steps Were Required
- the Linux md RAID device;
- the Btrfs filesystem sitting on top of it.
Both must expose the larger size before users see the extra capacity.
Treat This as a Version-Specific Community Procedure
The source user explicitly ran ZimaOS+ 1.5.4. Current ZimaOS is newer, and storage-management behavior can change. Before running manual mdadm --grow on production storage, verify that the UI still has no supported expand path and consider asking IceWhale support for the current procedure.
Verify RAID Health Before Each Physical Swap
Before replacing the first disk—and again before replacing the second—confirm the array is healthy and fully synchronized. Starting the second replacement while the first rebuild is incomplete removes the redundancy you are relying on during the upgrade.
Record the member serial numbers so the physical drive you remove matches the logical member shown by ZimaOS.
Replacement Drives Need Enough Real Capacity
Nominally equal-capacity drives can differ slightly in usable sector count. The safest expansion uses replacement disks that are clearly larger than the old members and at least as large as each other.
If the second “1 TB” drive is fractionally smaller than the first, the md grow/rebuild step may not behave as expected.
Expect More Than One Resync Cycle
The source workflow rebuilt after the first physical replacement, rebuilt after the second, and then entered another recovery/resync state after the mdadm --grow. That means a capacity upgrade can take substantially longer than simply swapping two disks.
Keep the NAS on reliable power and avoid unnecessary restarts during every recovery phase.
Verify Both the Block Device and Filesystem at the End
After the final Btrfs resize, verify the result from more than one layer:
-
mdadm --detail— md RAID geometry; -
df -hor Btrfs filesystem tools — usable filesystem capacity; - ZimaOS Storage UI — expected pool size and healthy state.
If one layer still shows the old size, stop and investigate instead of repeating grow commands blindly.
RAID 1 Expansion FAQ
Can one larger disk immediately increase RAID1 capacity?
No. The mirror remains constrained by the smaller member and historical array geometry.
Did replacing both smaller disks automatically increase capacity in the source?
No. The user still had to grow the md array and then resize Btrfs.
Was the manual grow workflow source-confirmed?
Yes, by one ZimaOS+ 1.5.4 user. It was not posted as an official IceWhale procedure.
