3

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 ~]$
|improve this question
  • Note that apparently dmsetup can be mislead by this and actually create an alignment problem; see unix.stackexchange.com/questions/421587/… (leaving this here for future readers) – derobert Feb 3 '18 at 6:13
  • Actually, upon closer inspection ... my question applies to your case too... Your LUKS data is misaligned. Unfortunately I doubt there is an easy fix if you've already got data on it (but maybe its not causing a performance issue for you, so you can just ignore) – derobert Feb 3 '18 at 6:26
  • @derobert I'm not using LUKS on this machine. The cause looks to be an incorrectly reported optimal_io_size, but you may have the same root cause (USB attached SATA). – Tom Hale Jan 25 at 5:28
3

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:

|improve this answer
  • 1
    33553920 % 4096 = 3584 = 7 sectors. So it isn't a false warning in this case — it's actually misaligned. – derobert Feb 3 '18 at 6:28
  • @derobert Although it is true that optimal_io_size is not a multiple of physical_block_size, neither of these is changeable. It's not really an alignment issue because it's not affected by the device partitioning/mapping. – Kevinoid Feb 3 '18 at 9:44
  • @derobert Ignore my previous reply. I just realized you were referring to the alignment of the partitions from the log snippet in the original question. I believe you may be correct that TomHale's partitions are misaligned. – Kevinoid Feb 3 '18 at 9:53
  • Is there any way to re-align an existing partition? I have an encrypted LUKS volume which was working for many months ... until one day it didn't -- I'd really like to be able to retrieve data without reformatting or re-creating the volume. – Daniel Dec 10 '18 at 18:47
  • Can you read SMART data (via smartctl) from the disk? If no, this answer may help. – Tom Hale Jan 25 at 5:12
1

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

|improve this answer
  • $ cat /sys/block/sdb/queue/optimal_io_size 33553920 33MB for a 2TB USB HDD? 268431360 for a 4TB??? – Tom Hale Jun 10 '17 at 5:17
  • @Tom they both should drop to 0 if you fix the alignment – user1133275 Jun 11 '17 at 10:38
  • 1
    I'm seeing this, but realised that 33553920 / 512 = 65535. Is it possible something's reporting "-1" as optimal IO size in sectors? – Steve Dee Mar 18 '18 at 11:33
0

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).

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.