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=33553920Jan 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=33553920Jan 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=34393292288Jan 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=34393292288What exactly is aligned incorrectly here? Can I make it consistent?Further info:[ravi@tara ~]$ uname -aLinux tara 4.8.17-1-MANJARO #1 SMP PREEMPT Mon Jan 9 10:24:58 UTC 2017 x86_64 GNU/Linux[ravi@tara ~]$ lsblkNAME                MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTsda                   8:0    0  3.7T  0 disksdb                   8:16   0  3.7T  0 disksdb1                8:17   0  200M  0 partsdb2                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  /arksdc                   8:32   1  7.5G  0 disksdc1                8:33   1  7.5G  0 partmmcblk0             179:0    0 29.1G  0 diskmmcblk0p1         179:1    0  200M  0 part /mnt/espmmcblk0p2         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 diskmmcblk0boot1        179:16   0    4M  1 diskmmcblk0rpmb         179:24   0    4M  0 disk[ravi@tara ~]$
Device mapper table alignment inconsistency
linux;device mapper
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.)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 in this case 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.  If this is your case, you can safely ignore the warning.