Hello, Starting with kernel 6.11.x series up to current 6.12-rc7 when I unlock my encrypted hdd (storage, not root) with cryptsetup: cryptsetup luksOpen /dev/sda1 hdd5 -d keyfile_hdd5 it triggers an alignment inconsistency: In dmesg log, I read: ---- [ 105.841278] device-mapper: table: 254:1: adding target device sda1 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=16777216 [ 105.841292] device-mapper: table: 254:1: adding target device sda1 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=16777216 [ 105.841601] device-mapper: table: 254:1: adding target device sda1 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=16777216 [ 105.841607] device-mapper: table: 254:1: adding target device sda1 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=16777216 ---- Also, starting with Linux >6.11.x up to current 6.12-rc7, "lsblk -t" returns different values than before in OPT-IO & RA column. ---- With kernel >6.11.x With device closed: NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME sda 0 4096 16776704 4096 512 1 bfq 256 32764 0B └─sda1 0 4096 16776704 4096 4096 1 bfq 256 32764 0B After luksOpen: sda 0 4096 16776704 4096 512 1 bfq 256 32764 0B └─sda1 0 4096 16776704 4096 512 1 bfq 256 32764 0B └─hdd5 -1 4096 0 4096 4096 1 32764 0B I tried to track down when this started exactly, to do so, I compiled kernel: 6.7.12, 6.8.12, 6.9.9, 6.10.14 and none of them returns this device-mapper inconsistency. lsblk -t with kernel 6.10.14 and earlier: NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME sda 0 4096 0 4096 512 1 bfq 256 128 0B └─sda1 0 4096 0 4096 512 1 bfq 256 128 0B └─hdd5 0 4096 0 4096 4096 1 128 0B So far, I have been able to locate this commit (part of Linux 6.11.x) a23634644afc2f7c1bac98776440a1f3b161819e (block: take io_opt and io_min into account for max_sectors ) that seems to trigger the change in lsblk output and introduces opt-io & ra value but as a casual user, I can't say for sure, I'm not a developer either. On the other hand, if I compile a kernel using one or two commit before a23634644afc2f7c1bac98776440a1f3b161819e then the lsblk -t output is not changed and no "device-mapper inconsistency" appears so it seems at least related somehow. By the way, after enteting my password (or using keyfile) cryptsetup returns no error and the filesystem (btrfs) mounts correctly. Let me know if you need other info. See also: https://gitlab.com/cryptsetup/cryptsetup/-/issues/919 System used: Gentoo The HDD is connected to an SAS HBA (Dell Perc H310 with IT firmware) Actually, there are also 4 other HDD (same brand, model, capacity, same configuration used) connected to it and they all show the exact same message "device-mapper inconsistency" as soon as there are unlocked. gdisk -l /dev/sda ---- Disk /dev/sda: 5860533168 sectors, 2.7 TiB Model: WDC WD30EZRX-00D Sector size (logical/physical): 512/4096 bytes Disk identifier (GUID): 4D31A7E7-A2A6-4A5A-8FE1-8368581B78DC Partition table holds up to 128 entries Main partition table begins at sector 2 and ends at sector 33 First usable sector is 34, last usable sector is 5860533134 Partitions will be aligned on 2048-sector boundaries Total free space is 2924 sectors (1.4 MiB) Number Start (sector) End (sector) Size Code Name 1 2048 5860532224 2.7 TiB 8300 Linux filesystem ---- luksDump /dev/sda1 ---- LUKS header information Version: 2 Epoch: 5 Metadata area: 16384 [bytes] Keyslots area: 16744448 [bytes] UUID: d1ff1c64-a294-4287-ab33-215327716e96 Label: hdd5 Subsystem: (no subsystem) Flags: (no flags) Data segments: 0: crypt offset: 16777216 [bytes] length: (whole device) cipher: serpent-xts-plain64 sector: 4096 [bytes] ----
