Lum – What does `cryptsetup resize` do if LUKS doesn’t store partition size

cryptsetupdevice-mapperdm-cryptluksvolume

The LUKS / dm-crypt / cryptsetup FAQ page says:

2.15 Can I resize a dm-crypt or LUKS partition?

Yes, you can, as neither dm-crypt nor LUKS stores partition size.

I'm befuzzled:

  1. What is "resized" if no size information is stored?

  2. How does a "resize" get remembered across open / closes of a encrypted volume?

Best Answer

It's about online resize.

For example if you use LVM, create a LV of 1G size, and put LUKS on that, it's like this:

# lvcreate -L1G -n test VG
# cryptsetup luksFormat /dev/mapper/VG-test
# cryptsetup luksOpen /dev/mapper/VG-test lukstest
# blockdev --getsize64 /dev/mapper/VG-test
1073741824
# blockdev --getsize64 /dev/mapper/lukstest
1071644672

So the LUKS device is about the same size as the VG-test device (1G minus 2MiB used by the LUKS header).

Now what happens when you make the LV larger?

# lvresize -L+1G /dev/mapper/VG-test
  Size of logical volume VG/test changed from 1.00 GiB (16 extents) to 2.00 GiB (32 extents).
  Logical volume test successfully resized.
# blockdev --getsize64 /dev/mapper/VG-test
2147483648
# blockdev --getsize64 /dev/mapper/lukstest
1071644672

The LV is 2G large now, but the LUKS device is still stuck at 1G, as that was the size it was originally opened with.

Once you luksClose and luksOpen, it would also be 2G — because LUKS does not store a size, it defaults to the device size at the time you open it. So close and open (or simply rebooting) would update the crypt mapping to the new device size. However, since you can only close a container after umounting/stopping everything inside of it, this is basically an offline resize.

But maybe you have a mounted filesystem on the LUKS, it's in use, and you don't want to umount it for the resize, and that's where cryptsetup resize comes in as an online resize operation.

# cryptsetup resize /dev/mapper/lukstest
# blockdev --getsize64 /dev/mapper/lukstest
2145386496

cryptsetup resize updates the active crypt mapping to the new device size, no umount required, and then you can follow it up with resize2fs or whatever to also grow the mounted filesystem itself online.

If you don't mind rebooting or remounting, you'll never need cryptsetup resize as it happens automatically offline. But if you want to do it online, that's the only way.

When shrinking (cryptsetup resize --size x), the resize is temporary. LUKS does not store device size, so next time you luksOpen, it will simply use the device size again. So shrinking sticks only if the backing device was also shrunk accordingly.

For a successful shrink you have to work backwards... growing is grow partition first, then LUKS, then filesystem... shrinking is shrink filesystem first, and partition last.

If the resize doesn't work, it's most likely due to the backing device not being resized, for example the kernel may refuse changes to the partition table while the drive is in use. Check with blockdev that all device layers have the sizes you expect them to have.

Related Question