Device mapper table alignment inconsistency

Question

In the journal, I'm getting lines such as:

Jan 27 18:23:08 tara kernel: device-mapper: table: 254:2: adding target device sdb2 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=33553920
Jan 27 18:23:08 tara kernel: device-mapper: table: 254:2: adding target device sdb2 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=33553920
Jan 27 18:23:08 tara kernel: device-mapper: table: 254:3: adding target device sdb2 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=34393292288
Jan 27 18:23:08 tara kernel: device-mapper: table: 254:3: adding target device sdb2 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=34393292288

How do I interpret this:

• What exactly is aligned incorrectly here?
• Where do the start= numbers come from?

How can I make the alignment consistent?

---

Further info:

[ravi@tara ~]$ uname -a
Linux tara 4.8.17-1-MANJARO #1 SMP PREEMPT Mon Jan 9 10:24:58 UTC 2017 x86_64 GNU/Linux
[ravi@tara ~]$ lsblk
NAME                MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                   8:0    0  3.7T  0 disk
sdb                   8:16   0  3.7T  0 disk
├─sdb1                8:17   0  200M  0 part
└─sdb2                8:18   0  3.7T  0 part
  ├─usb-eMMC_backup 254:2    0   32G  0 lvm
  └─usb-ark         254:3    0  3.6T  0 lvm  /ark
sdc                   8:32   1  7.5G  0 disk
└─sdc1                8:33   1  7.5G  0 part
mmcblk0             179:0    0 29.1G  0 disk
├─mmcblk0p1         179:1    0  200M  0 part /mnt/esp
└─mmcblk0p2         179:2    0 28.9G  0 part
  ├─lvm-root        254:0    0   24G  0 lvm  /
  └─lvm-swap        254:1    0  4.9G  0 lvm  [SWAP]
mmcblk0boot0        179:8    0    4M  1 disk
mmcblk0boot1        179:16   0    4M  1 disk
mmcblk0rpmb         179:24   0    4M  0 disk
[ravi@tara ~]$

Answer 1

The warning indicates that the partition and the LVM device may be misaligned, as defined by the checks in blk_stack_limits. You can examine the values from the output of lsblk -t /dev/sdb and check for the sorts of misalignments caught in blk_stack_limits (e.g. physical is multiple of logical block size, opt and min I/O are multiples of physical block size, etc.)

Update 2019-03-03: As @derobert pointed out in the comments, in this case the warnings are correct. Your PV starts at byte 33,553,920 which is not a multiple of the physical block size 4,096. To correct the issue, you would need to move or re-create the PV/partition to start on a multiple of 4,096 (e.g. by passing --dataalignment to vgcreate/pvcreate or --offset to cryptsetup).

Unfortunately, even after the start is corrected, the "alignment inconsistency" message will continue to be printed. The conclusion of Sven Eschenberg in a long thread on the dm-crypt list was that some of these checks may yield incorrect warnings. In particular, if sdb is a USB disk, the optimal I/O size may not be a multiple of the physical sector size (e.g. I have a 4k USB3 disk which reports physical_block_size 4,096 and optimal_io_size 33,553,920). These values are correct (as reported by the drive), plausible (due to USB constraints), and are not based on any of the device mapper parameters.

The problem is that the logic in blk_stack_limits assumes optimal I/O size will be a multiple of the physical sector size, which is not true for some devices. Once this is the only issue present, you can safely ignore the warning.

Update 2019-03-03: Unfortunately, several tools may create these incorrectly aligned PVs/partitions. Relevant issues/fixes:

• RedHat Bug 1513820 for cryptsetup (fixed in v2.0.0 - b80278c0)
• Debian Bug 923561 for parted (not fixed)
• util-linux libfdisk (fixed in v2.27 - acb7651f8)
• RedHat Bug 1685787 for lvm2 pvcreate (not fixed)

Answer 2

Alignment ensures optimal use of your drive, sometimes software gets this wrong and compensates by using a larger cache, check

cat /sys/block/sd?/queue/optimal_io_size

to correct that you have to re format (likely both the GPT/LVM layers) look into --dataalignment and --dataalignmentoffset of pvcreate

Answer 3

Interpretation

The value first start= value of 33553920 is the offset of the first PE of the first LV in the target device (above /dev/sdb2).

This can be confirmed by:

sudo pvs -o +pe_start --units b 

There is also another start= value repeated because sdb2's VG contains two LVs (usb-eMMC_backup and usb-ark). I don't know why each is repeated though.

Cause

An alignment inconsistency exists because pe_start is not divisible by the PHY-SEC value of:

lsblk -t /dev/sdb

PHY-SEC was 4096, and 33553920 % 4096 != 0.

All LVs in the VG will be misaligned if pe_start is misaligned (with the default PE size of 4MiB).

Resolution

The VG will need to be created such that pe_start is divisible by the disk's sector size.

Passing --dataalignment 1m to vgcreate will have pe_start = 1048576B = 1MiB

What if I'm still getting alignment inconsistency?

Assuming the underlying partition is aligned, there may still be an (incorrect) alignment message generated. See this answer for a possible cause and resolution, especially if using USB attached SATA (UAS).