1

I am trying to expand an existing RAID1 array with an ext4 filesystem on a LUKS volume on Debian GNU/Linux 10 (buster).

This is my disk layout from lsblk:

NAME              MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                 8:0    0   9,1T  0 disk
├─sda1              8:1    0    10M  0 part
├─sda2              8:2    0   477M  0 part
│ └─md0             9:0    0 476,7M  0 raid1 /boot
├─sda3              8:3    0  55,9G  0 part
│ └─md1             9:1    0  55,9G  0 raid1 /
└─sda4              8:4    0   7,2T  0 part
  └─md2             9:2    0   7,2T  0 raid1
    └─md2_crypt   253:0    0   7,2T  0 crypt /data
sdb                 8:16   0   9,1T  0 disk
├─sdb1              8:17   0    10M  0 part
├─sdb2              8:18   0   477M  0 part
│ └─md0             9:0    0 476,7M  0 raid1 /boot
├─sdb3              8:19   0  55,9G  0 part
│ └─md1             9:1    0  55,9G  0 raid1 /
└─sdb4              8:20   0   7,2T  0 part
  └─md2             9:2    0   7,2T  0 raid1
    └─md2_crypt   253:0    0   7,2T  0 crypt /data

I want to expand /data to take up the remaining free space. So this means expanding sda4, sdb4, and md2 and thus also md2_crypt and the filesystem on it.

This is how I plan to do this, but I am not sure this is correct:

  1. Unmount /data (umount /data)
  2. Close LUKS volume (cryptsetup luksClose md2_crypt)
  3. Fail and remove sda4 (mdadm -f /dev/md2 /dev/sda4 && mdadm -r /dev/md2 /dev/sda4)
  4. Delete partition /dev/sda4 and create a new one that takes up entire free disk space. (cgdisk /dev/sda4) Maybe I can just grow existing without deleting?
  5. Add back the resized sda4 (mdadm --add /dev/md2 /dev/sda4)
  6. Wait for it to sync (mdadm --wait /dev/md2)
  7. Repeat steps 4..6 with sdb4 instead of sda4.
  8. Remove write intend bitmap from raid array (mdadm --grow /dev/md2 -b none)
  9. Extend raid array (mdadm --grow /dev/md2 --size max)
  10. Wait for it to sync (mdadm --wait /dev/md2)
  11. Add back bitmap (mdadm --grow /dev/md2 --bitmap internal)
  12. Resize LUKS volume to take all available space (cryptsetup luksOpen md2_crypt && cryptsetup resize md2_crypt)
  13. fsck file system (e2fsck -f /dev/mapper/md2_crypt)
  14. Grow ext4 filesystem (resize2fs /dev/mapper/md2_crypt)
  15. Mount filesystem again (mount /data)

Is this approach correct? Am I missing important steps? Is the order correct? I am particularly concerned about the LUKS part as I have never grown LUKS before. Also, I am concerned about the write intend bitmap. Not sure if and when this is to be removed/added or if at all necessary.

Additional details:

This is my /proc/mdstat

Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md2 : active raid1 sda4[3] sdb4[4]
      7754802503 blocks super 1.2 [2/2] [UU]
      [=============>.......]  check = 66.6% (5170546304/7754802503) finish=237.0min speed=181708K/sec
      bitmap: 0/15 pages [0KB], 262144KB chunk

md1 : active raid1 sdb3[4] sda3[3]
      58560512 blocks super 1.2 [2/2] [UU]

md0 : active raid1 sdb2[4] sda2[3]
      488128 blocks super 1.2 [2/2] [UU]

unused devices: <none>

(it will be done sync'ing before I start this)

mdadm --detail /dev/md2

/dev/md2:
           Version : 1.2
     Creation Time : Sat Apr  1 20:30:05 2017
        Raid Level : raid1
        Array Size : 7754802503 (7395.56 GiB 7940.92 GB)
     Used Dev Size : 7754802503 (7395.56 GiB 7940.92 GB)
      Raid Devices : 2
     Total Devices : 2
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Wed Apr 12 16:57:07 2023
             State : clean, checking
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 0

Consistency Policy : bitmap

      Check Status : 66% complete

            Events : 235789

    Number   Major   Minor   RaidDevice State
       4       8       20        0      active sync   /dev/sdb4
       3       8        4        1      active sync   /dev/sda4

LUKS INFO:

LUKS header information for /dev/md2

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha1
Payload offset: 4096
MK bits:        512

fdisk -l /dev/sda

Disk /dev/sda: 9,1 TiB, 10000831348736 bytes, 19532873728 sectors
Disk model: MG06ACA10TE
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt

Device         Start         End     Sectors  Size Type
/dev/sda1       2048       22527       20480   10M BIOS boot
/dev/sda2      22528      999423      976896  477M Linux RAID
/dev/sda3     999424   118185983   117186560 55,9G Linux RAID
/dev/sda4  118185984 15628053134 15509867151  7,2T Linux RAID

parted /dev/sda print free output:

Warning: Not all of the space available to /dev/sda appears to be used, you can fix the GPT to use
all of the space (an extra 3904820560 blocks) or continue with the current setting?
Fix/Ignore? ^C
Model: ATA MG06ACA10TE (scsi)
Disk /dev/sda: 10,0TB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name  Flags
        17,4kB  1049kB  1031kB  Free Space
 1      1049kB  11,5MB  10,5MB                     bios_grub
 2      11,5MB  512MB   500MB                      raid
 3      512MB   60,5GB  60,0GB                     raid
 4      60,5GB  8002GB  7941GB                     raid
        8002GB  10,0TB  1999GB  Free Space
Improve this question

1 Answer 1

Reset to default
1

Way too many steps. You don't want to fail drives unless absolutely necessary. (※)

Assuming there is free, unpartitioned space available and no other partition in the way, you can just grow everything directly, in order. With online resize like this, there is no need to umount anything.

# Partition (repeat it for all disks)
parted /dev/sdx print free
parted /dev/sdx resizepart 4 100%

# RAID
mdadm --grow /dev/md2 --size=max
mdadm --wait /dev/md2

# LUKS
cryptsetup resize md2_crypt

# EXT4
resize2fs /dev/mapper/md2_crypt

You should check after each step that it actually worked, e.g. lsblk shows the new, larger size for the partition / md / crypt device after resizing it. Ideally, it should just work, but sometimes, the kernel refuses to re-read partition tables. In such a case, you might have to reboot after all.

(※) Although it could make sense in a different context — to keep an untouched mirror around while performing dangerous changes. But from your description, it does not seem like this was your intention. You would not be re-adding the drive at all, until everything else is done and verified to be working.

Improve this answer
10
  • This looks very simple... Do I not even have to unmount or luksClose anything?
    – Ellen Trendy
    Apr 12 at 18:43
  • @EllenTrendy if I understood your situation correctly, then you don't have to. It would be different if the free space was not at the end of disk but before the partition (growing to the left). Show print free output.
    – frostschutz
    Apr 12 at 18:54
  • not sure I understand what you mean by show print free output. You mean df? Filesystem Size Used Avail Use% Mounted on /dev/mapper/md2_crypt 7,2T 6,6T 242G 97% /data Update: Added fdisk -l output to the question.
    – Ellen Trendy
    Apr 12 at 19:34
  • I now realized what you meant by print free output. I'll add it to the post.
    – Ellen Trendy
    Apr 12 at 19:44
  • @EllenTrendy Did you copy these drives over with ddrescue or how did they grow larger, with GPT backup header not at the end of drive? That's the only questionable point, everything else is as expected.
    – frostschutz
    Apr 12 at 23:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .