Is it possible to grow a luks-encrypted external raid5 array?

5,434

Solution 1

Yep, you certainly can.

howto do it

First I needed to add the additional drives to the array as hot spares with the commands:

mdadm --add /dev/md2 /dev/sdc3

/dev/md2 being the raid, sdc3 the additional disk.

Then I told the array to grow [...] with:

"mdadm --grow -n 12 /dev/md2".

Now I waited around 16 hours for the array to restructure itself to the new layout. [...] Check cat /proc/mdstat to watch the progress.

Then I needed to tell the encrypted partition it was bigger. [...]

cryptsetup luksOpen /dev/md2 storage
cryptsetup resize storage

"storage" being the label of the encrypted device as in /dev/mapper/sotrage.

If this was a LVM partition, I'd have needed to do a pvresize instead of the above. Finally, I had to increase the size of the file-system. [...]

resize2fs /dev/mapper/storage

Do you lose any data on the array while doing this? Nope, it preserves all the data. I had run a "dd if=/dev/md2 of=/dev/zero" before doing the reshape on it, to make sure that there weren't any bad blocks on any of the drives before doing the reshape. Running this sort of verify can find marginal sectors that aren't normally used, and it's an important part of running a RAID array. Also, make sure that you don't have a failed drive before running the reshape.

Other useful bits:

You can't grow the file-system until the RAID resizing is completed.

Is it safe to do the RAID-5 resize while the device is in use? Yes, it should be. It's designed to keep track of where it is so you can even reboot while it's growing the array, and it will pick up where it left off.

Source: http://www.tummy.com/journals/entries/jafo_20080502_154339

Solution 2

Just a few clarifications, pre-chewed wisdom for weak teeth. Like a lot of Linux documentation this helpful tutorial assumes a little more knowledge than some regular users may have.

You can figure out what your RAID array is called by looking at the /dev directory, it will be md#, e.g. md0 or md1, etc. To get more details about the RAID arrays so you can pick the right one try this command:

 mdadm -D /dev/md#

with # being the number of the array. It will give you info like this:

Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

           Name : we:0  (local to host we)
           UUID : 94777f33ltjj97
         Events : 136

    Number   Major   Minor   RaidDevice State
       0       8        2        0      active sync   /dev/sda2
       1       8       18        1      active sync   /dev/sdb2
       2       8       34        2      active sync   /dev/sdc2
       4       8       50        3      active sync   /dev/sdd2

No quotation marks are present in the command to grow the RAID file system and the "-n" refers to the new total number of drives in the array. So if you are expanding a RAID 5 array from 4 to five drives you might use this:

mdadm --grow -n 5 /dev/md2

Run this command to see how the RAID incorporation is going:

cat /proc/mdstat

With a big drive and a slow system the resizing the RAID could take a very long time, even days. When it reaches 100% you are ready for the next step. If you have LVM partitioning over a LUKS encrypted partition first you need to resize the encrypted volume. To figure it out you can look at the /dev/mapper folder. Select the encrypted volume, not any of the LVM logical volumes.Since my system was running I apparently didn't need to do the first of the commands the tutorial gives:

  cryptsetup luksOpen /dev/md0 md0_crypt

    *Device md0_crypt already exists*

If the second command works it will not give any output, like so many Linux commands:

cryptsetup resize md0_crypt

Next it is time to resize the LVM scheme. I figured out what to run the pvresize command on with this command: pvs -o +tags

pvs -o +tags
  *PV         VG   Fmt  Attr PSize PFree PV Tags
  /dev/dm-0  vg0  lvm2 a--  1.02g    0* 

So I ran the pvresize command on the physical volume, and it told me it had succeeded.

pvresize /dev/dm-0
  *Physical volume "/dev/dm-0" changed
  1 physical volume(s) resized / 0 physical volume(s) not resized*

Next decide which logical volume you wish to expand with the lvdisplay command. That will tell you what your logical volumes are called. The name of your volume group will be in the /dev folder. In my case I used:

lvdisplay /dev/vg0

Look at the fields that say "LV Name" I decided to add all the new space to one of my logical volumes using this command:

lvresize -l +100%FREE /dev/mapper/vg0-system
  Extending logical volume system to 7.17 GiB
  Logical volume system successfully resized

Finally, you can resize the LVM so the changes take effect using the resize2fs command.

resize2fs /dev/mapper/vg0-system
*resize2fs 1.42.5 (29-Jul-2012)
Filesystem at /dev/mapper/vg0-system is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
Performing an on-line resize of /dev/mapper/vg0-system to 1879040 (4k) blocks.
The filesystem on /dev/mapper/vg0-system is now 1879040 blocks long.*

After that process finishes (which may take a while) you can use the 'df -h' command to see the new size of your file system. I found the whole process a little scary, so I wanted to spell out the commands to reduce anxiety for others.

Share:
5,434

Related videos on Youtube

con-f-use
Author by

con-f-use

physicist, programmer and lazy-ass

Updated on September 18, 2022

Comments

  • con-f-use
    con-f-use over 1 year

    I'm planing to buy an external raid array (hardware raid5). My intention is to outfit it with 4 disks initially and encrypt it using luks and dm-crypt. My question is: Will I be able to hot swap disks and grow the encrypted raid adding one or two more disks to a total of 6?

    I see no reason why not, but better safe than sorry. So is dm-crypt stable against growing partition size?

  • con-f-use
    con-f-use over 12 years
    I found out how to grow my hardware raid (no mdadm). The rest worked as your link described it. I have quoted the link for you so the information will remain on AskUbuntu even if the link 404.