Valid physical block size combinations of LVM physical volumes

If in your migration scenario the physical block size of a target physical volume (PV) is larger than the physical block size of the source PV, the file systems residing on logical volumes backed by the source PV may become corrupted. This is because the file system is aligned to the physical block size of the source PV and cannot be mapped to a larger block size. Therefore, never use a target volume with a larger block size than your source volumes.

The --sector-size parameter of a dm-crypt volume influences the physical block size. A dm-crypt volume encrypted with a sector size larger than the default 512 bytes results in a device with a physical block size of either the used sector size or the block size of the underlying device, whatever is higher.

This is the case for LUKS2 as well as for a plain mode dm-crypt volume. LUKS1 only supports the default block size of 512 bytes.

Migrating data from an unencrypted PV onto a dm-crypt encrypted PV might thus corrupt the file systems on the logical volumes backed by the source PV if the target dm-crypt volume uses a sector size of 4096 bytes, and the unencrypted source PV uses a physical block size of 512 bytes.

To query the physical block size of a device, use the following command:

# blockdev --getpbsz <device>

If the file systems on the affected LVs were created with a 4096 block size, then the problem does not occur. The file system may choose different block sizes based on various parameters. Thus, on larger volumes, it is very likely that the file system block size is 4096 by default.