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?

  • I don't think cryptsetup or LUKS affect the partition table. On a LUKS encrypted container, the disk partitioning is still performed by a tool like parted and stored in the partition table. I think the LUKS system is applied as a file format, i.e. you would partition the disk, then after that operation - which defines the partition size, then you would apply the LUKS file format, instead of say, ext4. So in short "resizing" just would not be applicable to LUKS. i.e. you wouldn't say Can I resize ext4? – the_velour_fog Nov 13 '16 at 7:47
  • man cryptsetup : "resize <name> Resizes an active mapping <name>. If --size (in sectors) is not specified, the size of the underlying block device is used. Note that this does not change the device geometry, it just changes how many sectors of the device are represented in the mapped device." – cylgalad Nov 13 '16 at 9:52
  • @the_velour_fog resize2fs resizes an ext2/3/4 BLOB as these have a concept of the a last block, see tune2fs -l. – Tom Hale Nov 13 '16 at 12:29
  • @cylgalad So how does one remember that "resize" across mounts? I couldn't see a mount option for this. – Tom Hale Nov 13 '16 at 12:34
  • I got my eyes checked: the open action has a --size argument. – Tom Hale Nov 13 '16 at 12:49

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
# blockdev --getsize64 /dev/mapper/lukstest

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
# blockdev --getsize64 /dev/mapper/lukstest

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

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.

  • has done a decent job of clarifying the question and giving some insight into what's going on - enough, surely, for the reward that comes from a green tick, especially in the absense of any other answers. The detailed explanation is evidence of labour and concern for the welfare of one's fellow hacks. But it is not a canonical answer to the questions posed - and that is what the reward was put up for: for the definitive statement on (i) What is "resized" if no size information is stored? and (ii) How does a "resize" get remembered across open / closes of a encrypted volume? – markling Jan 16 '18 at 18:19
  • @markling I thought it was clear enough, but here you go. – frostschutz Jan 16 '18 at 21:22
  • Yeah, it's a brilliant answer. I didn't know what I was talking about. I do now, however - now that I have read it again. Ah, I see - you edited it. Well I'm certainly wiser for it now. Thank you. – markling Mar 19 at 18:12

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.