fix(luks): use fixed data offset for consistent LUKS header size

[kvaps]

Summary

Different systems may create LUKS2 with different default header sizes (16 MiB vs 32 MiB) depending on system configuration (cryptsetup defaults, /etc/cryptsetup-default.conf, etc.).

This causes issues during toggle-disk operations when adding a disk to a diskless resource:

• DRBD expects the backing device size based on peer nodes
• The local LUKS device has less usable space due to a larger header
• Result: Low.dev. smaller than requested DRBD-dev. size error

Example:

• Node A (original): LUKS offset 32768 sectors (16 MiB), usable size 1073971328 sectors
• Node B (toggle-disk): LUKS offset 65536 sectors (32 MiB), usable size 1073938560 sectors
• DRBD cannot attach the smaller backing device

Solution

Always specify --offset 32768 (16 MiB) when creating LUKS devices to ensure consistent header size across all nodes. This is the minimum standard offset for LUKS2.

Also exclude --offset from additionalOptions to prevent users from accidentally breaking consistency.

[rp-]

LGTM, except we can't merge yet, as we have to remove rhel7 support first, as the old cryptsetup doesn't work with this.

for the other PR's I'll have to review/check them together with Gabor, who will be back next week.

[ghernadi]

I don't want to sound mean, but is /etc/cryptsetup-default.conf a hallucination? I could not find anything for that, so if you have some resources for me in that regard, I'd appreciate it.

If not using /etc/cryptsetup-default.conf or anything else that is external to LINSTOR I have to assume that you are using some LINSTOR property like StorDriver/LuksFormatOptions '--luks2-metadata-size 32M' (or --offset ...). That would also fit your proposed solution by simply ignoring such user-defined LUKS2 options in the CryptSetupCommands.java. However, as pointed out earlier --offset is just one way to screw up the size calculation, another would be --luks2-metadata-size, so you would need to ignore both.

If we already assume that all of the LUKS related options must be set in LINSTOR, a different approach (which honestly I would prefer) is to not ignore those properties but simply take them into account. We have for example the LuksLayerSizeCalculator that currently hardcoded adds 2MiB of space to the requested user-space for LUKS1 based setups and 16MiB to LUKS2 based setups. This (hardcoded) calculation of course is wrong if the user adds parameters like --offset or --luks2-metadata-size (or others that I am currently not aware of). LuksLayerSizeCalculator has already a method called getLuksHeaderSize, which should make it fairly easy to parse the properties, scan for --offset and other properties and return the correct size.

[kvaps]

@ghernadi you're right, /etc/cryptsetup-default.conf doesn't exist — I apologize for the confusion.

I've investigated the root cause and found it: ZFS zvols report optimal_io_size = 32 MiB, and cryptsetup uses this topology info for automatic data offset alignment.

Here's the evidence from my production cluster:

1. ZFS zvol topology parameters:

# cat /sys/block/zd720/queue/optimal_io_size
33554432
# cat /sys/block/zd720/queue/minimum_io_size
16384
# cat /sys/block/zd720/queue/physical_block_size
16384

2. Cryptsetup debug output when formatting without --offset:

# echo -n "pass" | cryptsetup -v --debug luksFormat --type luks2 /dev/zvol/data/test - 2>&1 | grep -i "topology\|offset"
# Topology: IO (16384/33554432), offset = 0; Required alignment is 33554432 bytes.
# Device size 104857600, offset 33554432.

3. Resulting LUKS header:

# cryptsetup luksDump /dev/zvol/data/test | grep offset
      offset: 33554432 [bytes]    # = 32 MiB

4. Same cryptsetup version on loop device (no optimal_io_size):

# cat /sys/block/loop0/queue/optimal_io_size
0
# cryptsetup luksDump /dev/loop0 | grep offset
      offset: 16777216 [bytes]    # = 16 MiB (default)

So the issue is: when creating LUKS on ZFS zvols without explicit --offset, cryptsetup picks up the 32 MiB optimal_io_size from block device topology. On other storage backends (LVM, loop
devices, etc.) where optimal_io_size is 0 or smaller, cryptsetup uses the default 16 MiB.

This causes inconsistent offsets when nodes run different kernel/zfs versions (with different topology handling behavior), or when new replicas are added after system updates that change the optimal_io_size reporting.