Talk:Resizing LVM-on-LUKS

From ArchWiki
Jump to navigation Jump to search

Safety buffers when shrinking LVM-on-LUKS

Shrinking Filesystem and Logical Volume

First of all, personally I can't see a reason for one to prefer resize2fs over the --resizefs option of lvresize. lvresize uses fsadm internally which, in addition to ext2/3/4, also supports ReiserFS and XFS (a little irrelevant to this topic as currently XFS doesn't support shrinking). So unless one would like to have a filesystem that's smaller than the LV, or is using a filesystem that's not supported by fsadm, resizing both the LV and the filesystem together should be a better option.

But if an unsupported filesystem is used, it is indeed better to have some safety buffer as --size 'with the + or - sign the value is added or subtracted from the actual size of the logical volume and rounded to the full extent size' (this sentence has been removed from the latest manual but it should still stand according to Red Hat's documentation). Although under most circumstances, since the extent size by default is 4M and most users would probably resize their LVs at gigabyte level, this should not be a problem, having such a safety buffer and optionally enlarge the filesystem later is generally safer and simpler.

FrederickZh (talk) 02:37, 28 August 2019 (UTC)

This was addressed by this change.
ChrisDunder (talk) 08:53, 29 December 2019 (UTC)

Shrinking Physical Volume and LUKS

Similar as shrinking filesystem and LV, the --size option of cryptsetup specifies the total size of the new LUKS volume including the LUKS header. So if the same size is used for both pvresize and cryptsetup, one will end up with a LUKS volume of which the data segment is actually smaller than the PV. Of course if the LUKS header is located in a different place this shouldn't be a problem but still under most circumstances, having such a buffer tends to be easier compared with working out the exact number here using cryptsetup luksDump info.

FrederickZh (talk) 02:37, 28 August 2019 (UTC)

This is false according to the man page: "For LUKS it is the size of the underlying device without the area reserved for LUKS header".
ChrisDunder (talk) 08:49, 29 December 2019 (UTC)


In a nutshell, I think the safety buffers here tend to be a bit excessive (~100MB should be more than enough) however may be treated as a safe and simple solution that covers several corner cases. But still I'd strongly suggest using lvresize --resizefs if the filesystem is supported by fsadm in the second step.

FrederickZh (talk) 02:37, 28 August 2019 (UTC)

This is no longer relevant since the safety buffer approach has been replaced by using precise formulas.
ChrisDunder (talk) 08:54, 29 December 2019 (UTC)