| View previous topic :: View next topic |
| Author |
Message |
sdauth
l33t
Joined: 19 Sep 2018
Posts: 643
Location: Ásgarðr
|
 Posted: Thu Oct 17, 2024 3:19 am Post subject: kernel 6.11.3 device-mapper alignment inconsistency |
 |
|
Hello,
I upgraded my kernel from 6.6.52 to 6.11.3, all good but this shows up in dmesg :
| Code: | [ 71.761899] device-mapper: table: 253:1: adding target device sde1 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=16777216
[ 71.761914] device-mapper: table: 253:1: adding target device sde1 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=16777216
[ 71.762139] device-mapper: table: 253:1: adding target device sde1 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=16777216
[ 71.762145] device-mapper: table: 253:1: adding target device sde1 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=16777216
[ 106.904936] device-mapper: table: 253:2: adding target device sdb1 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=16777216
[ 106.904951] device-mapper: table: 253:2: adding target device sdb1 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=16777216
[ 106.905203] device-mapper: table: 253:2: adding target device sdb1 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=16777216
[ 106.905208] device-mapper: table: 253:2: adding target device sdb1 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=16777216
[ 131.785762] device-mapper: table: 253:3: adding target device sdc1 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=16777216
[ 131.785777] device-mapper: table: 253:3: adding target device sdc1 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=16777216
[ 131.786028] device-mapper: table: 253:3: adding target device sdc1 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=16777216
[ 131.786034] device-mapper: table: 253:3: adding target device sdc1 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=16777216
[ 165.961267] device-mapper: table: 253:4: adding target device sdd1 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=16777216
[ 165.961281] device-mapper: table: 253:4: adding target device sdd1 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=16777216
[ 165.961549] device-mapper: table: 253:4: adding target device sdd1 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=16777216
[ 165.961555] device-mapper: table: 253:4: adding target device sdd1 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=16777216 |
disks are mounted correctly (btrfs on all disks) but there was no such warning with kernel 6.6.
| Code: | NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME
sdb 0 4096 16776704 4096 512 1 bfq 256 32764 0B
└─sdb1 0 4096 16776704 4096 512 1 bfq 256 32764 0B
└─hdd2 -1 4096 0 4096 512 1 32764 0B
sdc 0 4096 16776704 4096 512 1 bfq 256 32764 0B
└─sdc1 0 4096 16776704 4096 512 1 bfq 256 32764 0B
└─hdd3 -1 4096 0 4096 512 1 32764 0B
sdd 0 4096 16776704 4096 512 1 bfq 256 32764 0B
└─sdd1 0 4096 16776704 4096 512 1 bfq 256 32764 0B
└─hdd4 -1 4096 0 4096 512 1 32764 0B
sde 0 4096 16776704 4096 512 1 bfq 256 32764 0B
└─sde1 0 4096 16776704 4096 512 1 bfq 256 32764 0B
└─hdd -1 4096 0 4096 512 1 32764 0B |
The verify option of gdisk says :
| Code: | Warning: There is a gap between the main partition table (ending sector 33)
and the first usable sector (2048). This is helpful in some exotic configurations,
but is unusual. The util-linux fdisk program often creates disks like this.
Using 'j' on the experts' menu can adjust this gap.
Caution: Partition 1 doesn't end on a 2048-sector boundary. This may
result in problems with some disk encryption tools. |
In order to fix that, I would have to format them... isn't ?
Or maybe I can just ignore it ?
Thanks |
|
| Back to top |
|
 |
sdauth
l33t
Joined: 19 Sep 2018
Posts: 643
Location: Ásgarðr
|
| Posted: Fri Oct 18, 2024 3:54 pm Post subject: |
|
|
I think I found the "issue"..
Initially, the four disks (sdb sdc sdd sde) were each in a usb enclosure. (and were formatted via usb using fdisk)
I then added them (recently) in my server (sata), with no partition table modification or anything, only adding UUID & mountpoint to my fstab.
I think the formatting via USB caused the issue although I can't explain it. (I remember a similar issue with a firewire hdd dock years ago)
I made a test with the same kernel (6.11.3) on an other machine, with one hdd showing a similar gdisk warning :
| Code: | Warning: There is a gap between the main partition table (ending sector 33)
and the first usable sector (2048). This is helpful in some exotic configurations,
but is unusual. The util-linux fdisk program often creates disks like this.
Using 'j' on the experts' menu can adjust this gap.
Caution: Partition 1 doesn't end on a 2048-sector boundary. This may
result in problems with some disk encryption tools.
No problems found. 0 free sectors (0 bytes) available in 0
segments, the largest of which is 0 (0 bytes) in size. |
In this case, I used fdisk (a long time ago) as well but via sata directly (it is a laptop)
With kernel 6.11.3, no "device-mapper alignment inconsistency" warning.
| Code: | [ 5.345888] device-mapper: uevent: version 1.0.3
[ 5.346197] device-mapper: ioctl: 4.48.0-ioctl (2023-03-01) initialised: dm-devel@lists.linux.dev |
So even though I could just ignore it, I guess if I recreate the partition table on each disk, it should clear the warning.. stay tuned (will update this thread once I moved the data) 
EDIT : Unfortunately, it didn't help. I'm still having the same warning.
I noticed the lsblk -t output is different between kernel 6.6.52 & 6.11.3.
With 6.11.3 I have 16776704 for each disk in OPT-IO column.
With 6.6.52, it is set to 0.
Also, the fdisk is different as well, each disk reports :
| Code: | | I/O size (minimum/optimal): 4096 bytes / 16776704 bytes |
instead of (with kernel 6.6.52)
| Code: | | I/O size (minimum/optimal): 4096 bytes / 4096 bytes |
I have no idea how to solve this...
Anyway, looks like recreating the partition table was totally useless  Well, I will revert to 6.6.x series for now.. |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9801
Location: almost Mile High in the USA
|
| Posted: Sat Oct 19, 2024 8:52 pm Post subject: |
|
|
I don't know much about btrfs and I don't think this is relevant but I recently learned... that the RPi5 can have 16K page size instead of the typical 4K which incidentally is the perfect size for x86 and these AF hard drives. However this has nothing to do with the 16776704 which is exactly 2^24 - 512 bytes or (2^15-1) 512-blocks... which is indeed a weird number... I think it may be a regression in the 6.11 kernel but unsure, this size is weird.
The first time I read this post I was kind of surprised at the gdisk warning, on MBR disks there typically is normally a gap from the start of disk to the first usable data sector - mainly for the MBR, and also to hide MBR code like grub or other bootloader for classic boot computers, and why gdisk would complain about that I don't know. Perhaps it only is focused on GPT disks. Also perhaps this warning is a red herring to the kernel issue.
The 2048-boundary for encryption tools I'd call that a encryption tool bug but it's reasonable if the block cypher handles 2048 sectors (1MB assuming 512-byte sectors) at a time. I think LVM also has a minimum chunk size which is similar but it will automatically round down.
Hope you have backups (done under 6.6) ... just in case. Is the array slower under 6.11? 32767 as an optimal read count is both immense and weird.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
sdauth
l33t
Joined: 19 Sep 2018
Posts: 643
Location: Ásgarðr
|
| Posted: Sun Oct 20, 2024 4:02 am Post subject: |
|
|
eccerr0r, with kernel 6.11.3, just before trying to recreate the partition table (disk fully blank), this was the "lsblk -t" output.
| Code: | NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME
sdb 0 4096 16776704 4096 512 1 bfq 256 32764 0B
sdc 0 4096 16776704 4096 512 1 bfq 256 32764 0B
sdd 0 4096 16776704 4096 512 1 bfq 256 32764 0B
sde 0 4096 16776704 4096 512 1 bfq 256 32764 0B |
So no partition table, no file system yet. Funny values indeed.
I then rebooted to 6.6.52 :
| Code: | NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME
sdb 0 4096 0 4096 512 1 bfq 256 128 0B
sdc 0 4096 0 4096 512 1 bfq 256 128 0B
sdd 0 4096 0 4096 512 1 bfq 256 128 0B
sde 0 4096 0 4096 512 1 bfq 256 128 0B |
And as you can see, no problem here. So I recreated the partition table, crypto, fs.. and moved the data again from my backup, everything works as usual.
By the way those disks are connected to a raid controller (a perc h310, in IT mode, using mpt3sas) but there is no array involved here.
One other thing I noticed with kernel 6.11.3 is that if I plug sdb (for example) to one sata port on the motherboard instead, then the lsblk -t value is correct.
| Code: | NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME
sdb 0 4096 0 4096 512 1 bfq 256 128 0B |
So with kernel >6.11.3 and for disks connected to the raid card, it triggers a change in optimize_io_size (& ra ) with or without partition table, fs..
And I can also reproduce the issue on a other machine (different mb, cpu but same raid controller, with 8 disks connected), as soon as I try kernel >6.11.x, it shows the same funny values in "lsblk -t". If I reboot to 6.6.52, then back to normal. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
