I've recently switched my NAS with a single 4 TB disk to a RAID setup, with the goal of implementing a 3-disk RAID5. To do this without a 4th disk and without loosing my data, I first set up the 2 new disks as a RAID0, put the existing data onto it, and tried to add that disk to the RAID as well, growing it to a 3-disk RAID5.

This worked well up to the final step. The third disk (ok, strictly speaking it's a 4TB partition called sdb4 on a 6TB disk) was successfully added to the RAID and the grow to RAID5 worked. The trouble is that the RAID doesn't include the space on the new disk, and any attempting at using mdadm --grow gives me the message mdadm: /dev/md1 is performing resync/recovery and cannot be reshaped. That is consistent with the outputs of cat /proc/mdstat and mdadm --detail /dev/md1 (copied below), but the resyncing isn't actually happening, it is in a delayed state.

So the first concrete question is: how can I safely get mdadm to know that it does not need to resync right now, so that I can grow the RAID to include the third disk's space, and then to start syncing/calculating parity?

The other question is what the right command will be to actually grow the RAID to include that disk's space. So far, mdadm --grow /dev/md1 --size=max seems to be my best option - does that seem right?

Here is the promised output:

>cat /proc/mdstat 
Personalities : [raid0] [raid6] [raid5] [raid4] 
md1 : active raid5 sdb4[3] sdc1[1] sda1[0]
  7814034432 blocks super 1.2 level 5, 512k chunk, algorithm 5 [3/2] [UU_]

unused devices: <none>

and of mdadm --detail:

mdadm --detail /dev/md1 
    Version : 1.2
  Creation Time : Mon Jul 20 16:19:18 2015
 Raid Level : raid5
 Array Size : 7814034432 (7452.04 GiB 8001.57 GB)
 Used Dev Size : 3907017216 (3726.02 GiB 4000.79 GB)
 Raid Devices : 3
 Total Devices : 3
 Persistence : Superblock is persistent

Update Time : Sat Jul 25 11:25:45 2015
      State : clean, degraded, resyncing (DELAYED) 
Active Devices : 2
Working Devices : 3
Failed Devices : 0
Spare Devices : 1

     Layout : parity-last
 Chunk Size : 512K

       Name : thevault:1  (local to host thevault)
       UUID : 6dda752a:768df5aa:e74f49d8:7f60ea35
     Events : 70

Number   Major   Minor   RaidDevice State
   0       8        1        0      active sync   /dev/sda1
   1       8       33        1      active sync   /dev/sdc1
   3       8       20        2      spare rebuilding   /dev/sdb4

Thanks for helping out!

  • Using a RAID5 with 4TB disks is an extremely bad idea. Use RAID6/10 instead to increase the resilience against failures. – Sven Jul 25 '15 at 22:22
  • Thanks Sven. Right now it's the best I can do; maybe I'll switch to 6 or 10 in the future. So far I've only had off-site backup, now I'll be combining RAID5 with offsite. If I've read through the reasoning of why I shouldn't do this and I think I understand it. But it also seems to have nothing to do with the problem at hand (and right now my system is sitting in the terrible state of a 2-disk RAID5 with no on-site backup...). – anjrp Jul 26 '15 at 18:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.