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
3
  • 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) Commented Feb 3, 2018 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) Commented Feb 3, 2018 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). Commented Jan 25, 2019 at 5:28

3 Answers 3

Reset to default
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
5
  • 1
    33553920 % 4096 = 3584 = 7 sectors. So it isn't a false warning in this case — it's actually misaligned. Commented Feb 3, 2018 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. Commented Feb 3, 2018 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. Commented Feb 3, 2018 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. Commented Dec 10, 2018 at 18:47
  • Can you read SMART data (via smartctl) from the disk? If no, this answer may help. Commented Jan 25, 2019 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
4
  • $ cat /sys/block/sdb/queue/optimal_io_size 33553920 33MB for a 2TB USB HDD? 268431360 for a 4TB??? Commented Jun 10, 2017 at 5:17
  • @Tom they both should drop to 0 if you fix the alignment Commented Jun 11, 2017 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? Commented Mar 18, 2018 at 11:33
  • A weird optimal_io_size is a symptom of this issue Commented Dec 6, 2019 at 4:10
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

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.