19

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?

5
  • 1
    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? Commented Nov 13, 2016 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." Commented Nov 13, 2016 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. Commented Nov 13, 2016 at 12:29
  • @cylgalad So how does one remember that "resize" across mounts? I couldn't see a mount option for this. Commented Nov 13, 2016 at 12:34
  • I got my eyes checked: the open action has a --size argument. Commented Nov 13, 2016 at 12:49

1 Answer 1

30
+50

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.

7
  • 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? Commented Jan 16, 2018 at 18:19
  • @markling I thought it was clear enough, but here you go. Commented Jan 16, 2018 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. Commented Mar 19, 2019 at 18:12
  • can you add a bit more information ? I did the resize2fs on my partiion, my lvdisplay and pvdisplay shows the shrinked size? How can I make the volume smaller now? as far as I understand here, cryptsetup only reports a size, but does not store or have a size? so I guess next step is to go a level higher. My volume is a VirtualBox .vdi image file. is there an extra layer between VBox and Luks? I don't know. Thanks Commented Apr 27, 2021 at 3:42
  • 1
    some small precision here, --getsize64 gives a size 512 times bigger than what you want to give to cryptsetup resize --size Commented Apr 27, 2021 at 3:54

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.