F35: CHANGE: Optimal LUKS Encryption Sector Size

[jlebon]

In #856 we evaluated and decided to discuss further the following change:

• Optimal LUKS Encryption Sector Size
  • Autodetect optimal encryption sector size during Fedora installation with LUKS/dm-crypt encryption. On devices with 4k (physical) sector size, this will make sure we use 4096 sector size which is optimal for these devices.
  • Tracking bug: #1982417

From the change proposal, it looks like cryptsetup will just do the right thing on 4K native disks. So this should just be about sanity-checking that LUKS via Ignition is using the expected sector size on 4K. Optionally in the form of a test.

[ravanelli]

I got that tested for F35

[core@linux ~]$ rpm -qa | grep cryptsetup
cryptsetup-libs-2.4.0-1.fc35.x86_64
cryptsetup-2.4.0-1.fc35.x86_64

[core@linux ~]$ rpm -qa | grep libblockdev

512 Disk

[core@linux ~]$ lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINTS
sda      8:0    0   12G  0 disk
├─sda1   8:1    0    1M  0 part
├─sda2   8:2    0  127M  0 part
├─sda3   8:3    0  384M  0 part  /boot
└─sda4   8:4    0 11.5G  0 part  /var
                                 /usr
                                 /etc
                                 /
                                 /sysroot
sdb      8:16   0   12G  0 disk
└─data 253:0    0   12G  0 crypt /var/lib/data


sudo cryptsetup luksDump /dev/sdb | grep "sector"
sector: 512 [bytes]


fdisk -l /dev/sdb
Disk model: QEMU HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

4k Disk

sudo cryptsetup luksDump /dev/sdb | grep "sector"
sector: 4096 [bytes]
 
fdisk -l /dev/sdb
Disk /dev//sdb: 10 GiB, 10737418240 bytes, 2621440 sectors
Disk model: QEMU HARDDISK
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

[jlebon]

Nice, thanks @ravanelli!

Let's just close this out one. I initially suggested maybe making it a test, though I'm not sure it's worth it since we didn't actually have to change anything and it's mostly transparent to our stack. We don't currently have a LUKS-on-4k test, which could make sense to add for its own sake, and then we could add this check there.

[dustymabe]

Thanks @ravanelli

[ravanelli]

Let's just close this out one. I initially suggested maybe making it a test, though I'm not sure it's worth it since we didn't actually have to change anything and it's mostly transparent to our stack. We don't currently have a LUKS-on-4k test, which could make sense to add for its own sake, and then we could add this check there.

Yeah that make sense @jlebon! I think I lost this test part, but I can work with this test for LUKS-on-4k, I think it will be easy to do. I should probably open a ticket to track it?

[jlebon]

Let's just close this out one. I initially suggested maybe making it a test, though I'm not sure it's worth it since we didn't actually have to change anything and it's mostly transparent to our stack. We don't currently have a LUKS-on-4k test, which could make sense to add for its own sake, and then we could add this check there.

Yeah that make sense @jlebon! I think I lost this test part, but I can work with this test for LUKS-on-4k, I think it will be easy to do. I should probably open a ticket to track it?

Sure, sounds good! 👍