mjhjmtu

I want to remove my swap LVM LV out of its current LUKS container, and have it unencrypted instead.

I want to avoid something like gparted to have control of every step in the process.

1. After doing lvremove on the swap LV and pvmove to get contiguous PV extents, how do I work out the minimum size to pass to pvresize?




2. Given the now shrunken PV, how do I work out exactly how many sectors or MiB the LUKS container should contain, so I can shrink the LUKS partition to match?




3. Am I right in thinking that a LUKS container doesn't have a length, and is shrunk by simply shrinking the partition?




4. Is there a way of checking at the LVM level that the final extents of the PV are still accessible, ie, that they are indeed inside the shrunken partition's addressable sectors?

1.)

From the man page:

pvresize will refuse to shrink PhysicalVolume if it has allocated extents after where its new end would be.

So you could just do this by trial & error. Actually pvresize will tell you part of it:

/dev/dm-7: cannot resize to 17564 extents as 18620 are allocated.

To determine the exact size, you need to know the PE size (e.g. 4MiB) and 1st PE offset (e.g. 1MiB). And of course, the number of the last allocated extent.

pvs -o pv_name,pe_start,vg_extent_size,seg_pe_ranges

So the total size could for example be 1MiB (1st PE) + 18620 * 4MiB (PE size).

2.)

You need to know the LUKS header size / data offset. Usually this is 4096 sectors, i.e. 2MiB. Check with cryptsetup luksDump, Payload offset.

So your new partition size is the LUKS Payload offset plus whatever size you resized the PV itself to.

3.)

Yes and no. LUKS doesn't keep the size in its metadata, so if you are going to close the LUKS container, or even reboot, then yes, it will just use the size of the block device itself.

But for an online resize, you would need to set it with cryptsetup resize, to whatever size you used in pvresize.

4.)

I sometimes do this by passing the offending device in read-only mode to a qemu/KVM instance, running some Linux rescue system. It's hard to check on the host (with, say, a read-only loop device) because LVM doesn't like to see duplicate PV UUIDs, or VG/LV names. LVM will refuse to activate, should the PV turn out to be smaller than expected.

Consider pvshrink which does most of the calculations in frostschutz's answer, and has a --test mode which doesn't make any changes.