Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #198063 > unrolled thread
| Started by | Rick Thomas <rbthomas@pobox.com> |
|---|---|
| First post | 2018-07-28 03:50 +0200 |
| Last post | 2018-07-29 17:20 +0200 |
| Articles | 10 — 3 participants |
Back to article view | Back to linux.debian.user
kernel: device-mapper: table: 254:1: adding target device sda1 caused an alignment inconsistency Rick Thomas <rbthomas@pobox.com> - 2018-07-28 03:50 +0200
Re: kernel: device-mapper: table: 254:1: adding target device sda1 caused an alignment inconsistency Rick Thomas <rbthomas@pobox.com> - 2018-07-28 04:00 +0200
Re: kernel: device-mapper: table: 254:1: adding target device sda1 caused an alignment inconsistency David Wright <deblis@lionunicorn.co.uk> - 2018-07-28 05:30 +0200
Re: kernel: device-mapper: table: 254:1: adding target device sda1 caused an alignment inconsistency Rick Thomas <rbthomas@pobox.com> - 2018-07-28 09:30 +0200
Re: kernel: device-mapper: table: 254:1: adding target device sda1 caused an alignment inconsistency Rick Thomas <rbthomas@pobox.com> - 2018-07-28 11:30 +0200
Re: kernel: device-mapper: table: 254:1: adding target device sda1 caused an alignment inconsistency Henrique de Moraes Holschuh <hmh@debian.org> - 2018-07-28 16:00 +0200
Re: kernel: device-mapper: table: 254:1: adding target device sda1 caused an alignment inconsistency David Wright <deblis@lionunicorn.co.uk> - 2018-07-28 21:10 +0200
Re: kernel: device-mapper: table: 254:1: adding target device sda1 caused an alignment inconsistency Henrique de Moraes Holschuh <hmh@debian.org> - 2018-07-28 22:30 +0200
Re: kernel: device-mapper: table: 254:1: adding target device sda1 caused an alignment inconsistency Rick Thomas <rbthomas@pobox.com> - 2018-07-29 00:30 +0200
Re: kernel: device-mapper: table: 254:1: adding target device sda1 caused an alignment inconsistency David Wright <deblis@lionunicorn.co.uk> - 2018-07-29 17:20 +0200
| From | Rick Thomas <rbthomas@pobox.com> |
|---|---|
| Date | 2018-07-28 03:50 +0200 |
| Subject | kernel: device-mapper: table: 254:1: adding target device sda1 caused an alignment inconsistency |
| Message-ID | <wgmwN-7fc-1@gated-at.bofh.it> |
When booting, I get 12 error messages similar to the following (three groups of four, each group with a different “start” value and corresponding minor device) > Jul 24 03:40:08 small kernel: device-mapper: table: 254:1: adding target device sda1 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=33553920 Can anyone tell me what it means and what I should do about it? Thanks! Rick ============================ Information that might be useful: > rbthomas@small:~$ lsblk > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT > sda 8:0 0 931.5G 0 disk > `-sda1 8:1 0 931.5G 0 part > |-small-swap 254:0 0 10G 0 lvm [SWAP] > |-small-root 254:1 0 30G 0 lvm / > `-small-home 254:2 0 100G 0 lvm /home > mmcblk2 179:0 0 3.7G 0 disk > |-mmcblk2p1 179:1 0 512M 0 part /boot/efi > `-mmcblk2p2 179:2 0 2G 0 part /boot > rbthomas@small:~$ sudo gdisk -l /dev/sda > GPT fdisk (gdisk) version 1.0.3 > > Partition table scan: > MBR: protective > BSD: not present > APM: not present > GPT: present > > Found valid GPT with protective MBR; using GPT. > Disk /dev/sda: 1953525168 sectors, 931.5 GiB > Model: nal USB 3.0 > Sector size (logical/physical): 512/4096 bytes > Disk identifier (GUID): F040A793-41E6-46E6-9147-FED15A526294 > Partition table holds up to 128 entries > Main partition table begins at sector 2 and ends at sector 33 > First usable sector is 34, last usable sector is 1953525134 > Partitions will be aligned on 2048-sector boundaries > Total free space is 2014 sectors (1007.0 KiB) > > Number Start (sector) End (sector) Size Code Name > 1 2048 1953525134 931.5 GiB 8E00 Linux LVM > rbthomas@small:~$ > rbthomas@small:~$ sudo lvdisplay > --- Logical volume --- > LV Path /dev/small/root > LV Name root > VG Name small > LV UUID brZiAH-bjpQ-ThUf-cx20-qTNc-uHuL-dcNrA6 > LV Write Access read/write > LV Creation host, time grml, 2018-07-23 02:10:20 -0700 > LV Status available > # open 1 > LV Size 30.00 GiB > Current LE 7680 > Segments 1 > Allocation inherit > Read ahead sectors auto > - currently set to 256 > Block device 254:1 > > --- Logical volume --- > LV Path /dev/small/swap > LV Name swap > VG Name small > LV UUID UyLz6P-ooDS-hixd-D40U-EHEn-j2ss-xSEHay > LV Write Access read/write > LV Creation host, time grml, 2018-07-23 02:10:52 -0700 > LV Status available > # open 2 > LV Size 10.00 GiB > Current LE 2560 > Segments 1 > Allocation inherit > Read ahead sectors auto > - currently set to 256 > Block device 254:0 > > --- Logical volume --- > LV Path /dev/small/home > LV Name home > VG Name small > LV UUID qMdtCI-DOBG-G1tK-ur04-mLHX-nccd-vPWPEH > LV Write Access read/write > LV Creation host, time grml, 2018-07-23 02:11:12 -0700 > LV Status available > # open 1 > LV Size 100.00 GiB > Current LE 25600 > Segments 1 > Allocation inherit > Read ahead sectors auto > - currently set to 256 > Block device 254:2 > > rbthomas@small:~$ > rbthomas@small:~$ sudo pvdisplay -v > Wiping internal VG cache > Wiping cache of LVM-capable devices > --- Physical volume --- > PV Name /dev/sda1 > VG Name small > PV Size 931.51 GiB / not usable 32.69 MiB > Allocatable yes > PE Size 4.00 MiB > Total PE 238459 > Free PE 202619 > Allocated PE 35840 > PV UUID 4PuUWe-01xm-mtQE-nEtt-HSXZ-ZRyd-uZypdH > rbthomas@small:~$ sudo vgdisplay > --- Volume group --- > VG Name small > System ID > Format lvm2 > Metadata Areas 1 > Metadata Sequence No 5 > VG Access read/write > VG Status resizable > MAX LV 0 > Cur LV 3 > Open LV 3 > Max PV 0 > Cur PV 1 > Act PV 1 > VG Size 931.48 GiB > PE Size 4.00 MiB > Total PE 238459 > Alloc PE / Size 35840 / 140.00 GiB > Free PE / Size 202619 / 791.48 GiB > VG UUID SFb0ZB-EeSj-jYmd-F6FJ-7Jdh-imsH-v688ZZ > >
[toc] | [next] | [standalone]
| From | Rick Thomas <rbthomas@pobox.com> |
|---|---|
| Date | 2018-07-28 04:00 +0200 |
| Message-ID | <wgmGt-7iG-11@gated-at.bofh.it> |
| In reply to | #198063 |
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 shareimprove this answer edited Jun 8 '17 at 7:26 answered Jun 8 '17 at 7:18 user1133275 1,932412 • $ 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 • 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 at 11:33
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2018-07-28 05:30 +0200 |
| Subject | Re: kernel: device-mapper: table: 254:1: adding target device sda1 caused an alignment inconsistency |
| Message-ID | <wgo5z-8oZ-1@gated-at.bofh.it> |
| In reply to | #198063 |
On Fri 27 Jul 2018 at 18:46:02 (-0700), Rick Thomas wrote: > When booting, I get 12 error messages similar to the following (three groups of four, each group with a different “start” value and corresponding minor device) > > > Jul 24 03:40:08 small kernel: device-mapper: table: 254:1: adding target device sda1 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=33553920 > > Can anyone tell me what it means and what I should do about it? That's the same message as I reported on an MBR disk in https://lists.debian.org/debian-user/2018/02/msg00466.html The post gives full details of the partitioning and the creation of the encrypted filesystem which precede getting the messages (in pairs). There were no follow-ups. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Rick Thomas <rbthomas@pobox.com> |
|---|---|
| Date | 2018-07-28 09:30 +0200 |
| Message-ID | <wgrPP-2ga-7@gated-at.bofh.it> |
| In reply to | #198066 |
On Jul 27, 2018, at 8:19 PM, David Wright <deblis@lionunicorn.co.uk> wrote:
> On Fri 27 Jul 2018 at 18:46:02 (-0700), Rick Thomas wrote:
>> When booting, I get 12 error messages similar to the following (three groups of four, each group with a different “start” value and corresponding minor device)
>>
>>> Jul 24 03:40:08 small kernel: device-mapper: table: 254:1: adding target device sda1 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=33553920
>>
>> Can anyone tell me what it means and what I should do about it?
>
> That's the same message as I reported on an MBR disk in
> https://lists.debian.org/debian-user/2018/02/msg00466.html
>
> The post gives full details of the partitioning and the
> creation of the encrypted filesystem which precede getting
> the messages (in pairs).
>
> There were no follow-ups.
Googling the contents of the subject line of this post gives:
https://unix.stackexchange.com/questions/340484/device-mapper-table-alignment-inconsistency
which is slightly helpful.
Something else that is interesting is the following from “man pvcreate”:
> If a device is a 4KiB sector drive that compensates for windows partitioning (sector 7 is the lowest aligned logical
> block, the 4KiB sectors start at LBA -1, and consequently sector 63 is aligned on a 4KiB boundary) manually account
> for this when initializing for use by LVM.
> pvcreate --dataalignmentoffset 7s /dev/sdb
Is it possible that I have such a device?
Enjoy!
Rick
[toc] | [prev] | [next] | [standalone]
| From | Rick Thomas <rbthomas@pobox.com> |
|---|---|
| Date | 2018-07-28 11:30 +0200 |
| Message-ID | <wgtHY-3on-9@gated-at.bofh.it> |
| In reply to | #198067 |
Here’s something interesting that may be relevant, given the note from “man pvcreate”: > rbthomas@small:~$ lsblk -t > NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME > sda 0 4096 33553920 4096 512 1 mq-deadline 60 128 0B > `-sda1 0 4096 33553920 4096 512 1 mq-deadline 60 128 0B > |-small-swap -1 4096 0 4096 512 1 128 128 32M > |-small-root -1 4096 0 4096 512 1 128 128 32M > `-small-home -1 4096 0 4096 512 1 128 128 32M > mmcblk2 0 512 0 512 512 0 mq-deadline 128 128 0B > |-mmcblk2p1 0 512 0 512 512 0 mq-deadline 128 128 0B > `-mmcblk2p2 0 512 0 512 512 0 mq-deadline 128 128 0B > rbthomas@small:~$ Note the alignment values of “-1” for the lvm entries but not for the GPT partition or the whole disk. Why do you suppose that is? Rick On Jul 28, 2018, at 12:26 AM, Rick Thomas <rbthomas@pobox.com> wrote: > > On Jul 27, 2018, at 8:19 PM, David Wright <deblis@lionunicorn.co.uk> wrote: > >> On Fri 27 Jul 2018 at 18:46:02 (-0700), Rick Thomas wrote: >>> When booting, I get 12 error messages similar to the following (three groups of four, each group with a different “start” value and corresponding minor device) >>> >>>> Jul 24 03:40:08 small kernel: device-mapper: table: 254:1: adding target device sda1 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=33553920 >>> >>> Can anyone tell me what it means and what I should do about it? >> >> That's the same message as I reported on an MBR disk in >> https://lists.debian.org/debian-user/2018/02/msg00466.html >> >> The post gives full details of the partitioning and the >> creation of the encrypted filesystem which precede getting >> the messages (in pairs). >> >> There were no follow-ups. > > Googling the contents of the subject line of this post gives: > > https://unix.stackexchange.com/questions/340484/device-mapper-table-alignment-inconsistency > > which is slightly helpful. > > Something else that is interesting is the following from “man pvcreate”: > >> If a device is a 4KiB sector drive that compensates for windows partitioning (sector 7 is the lowest aligned logical >> block, the 4KiB sectors start at LBA -1, and consequently sector 63 is aligned on a 4KiB boundary) manually account >> for this when initializing for use by LVM. >> pvcreate --dataalignmentoffset 7s /dev/sdb > > Is it possible that I have such a device? > > Enjoy! > Rick
[toc] | [prev] | [next] | [standalone]
| From | Henrique de Moraes Holschuh <hmh@debian.org> |
|---|---|
| Date | 2018-07-28 16:00 +0200 |
| Subject | Re: kernel: device-mapper: table: 254:1: adding target device sda1 caused an alignment inconsistency |
| Message-ID | <wgxVg-5Nn-1@gated-at.bofh.it> |
| In reply to | #198069 |
On Sat, 28 Jul 2018, Rick Thomas wrote: > > rbthomas@small:~$ lsblk -t > > NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME > > sda 0 4096 33553920 4096 512 1 mq-deadline 60 128 0B > > `-sda1 0 4096 33553920 4096 512 1 mq-deadline 60 128 0B > > |-small-swap -1 4096 0 4096 512 1 128 128 32M > > |-small-root -1 4096 0 4096 512 1 128 128 32M > > `-small-home -1 4096 0 4096 512 1 128 128 32M > > mmcblk2 0 512 0 512 512 0 mq-deadline 128 128 0B > > |-mmcblk2p1 0 512 0 512 512 0 mq-deadline 128 128 0B > > `-mmcblk2p2 0 512 0 512 512 0 mq-deadline 128 128 0B > > rbthomas@small:~$ > > Note the alignment values of “-1” for the lvm entries but not for the GPT partition or the whole disk. > Why do you suppose that is? Keep in mind that you *offset*-align the outer container *only*, and then inside you just keep the size alignment. So, the above ensures correct use of the partitions even if sda1 is unaligned. If you offset-align sda1 to -1, everything inside it should have an offset of zero to keep the alignment correct. -- Henrique Holschuh
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2018-07-28 21:10 +0200 |
| Subject | Re: kernel: device-mapper: table: 254:1: adding target device sda1 caused an alignment inconsistency |
| Message-ID | <wgCLg-uc-7@gated-at.bofh.it> |
| In reply to | #198071 |
On Sat 28 Jul 2018 at 10:57:45 (-0300), Henrique de Moraes Holschuh wrote: > On Sat, 28 Jul 2018, Rick Thomas wrote: > > > rbthomas@small:~$ lsblk -t > > > NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME > > > sda 0 4096 33553920 4096 512 1 mq-deadline 60 128 0B > > > `-sda1 0 4096 33553920 4096 512 1 mq-deadline 60 128 0B > > > |-small-swap -1 4096 0 4096 512 1 128 128 32M > > > |-small-root -1 4096 0 4096 512 1 128 128 32M > > > `-small-home -1 4096 0 4096 512 1 128 128 32M > > > mmcblk2 0 512 0 512 512 0 mq-deadline 128 128 0B > > > |-mmcblk2p1 0 512 0 512 512 0 mq-deadline 128 128 0B > > > `-mmcblk2p2 0 512 0 512 512 0 mq-deadline 128 128 0B > > > rbthomas@small:~$ > > > > Note the alignment values of “-1” for the lvm entries but not for the GPT partition or the whole disk. > > Why do you suppose that is? > > Keep in mind that you *offset*-align the outer container *only*, and then inside > you just keep the size alignment. > > So, the above ensures correct use of the partitions even if sda1 is > unaligned. > > If you offset-align sda1 to -1, everything inside it should have an offset of > zero to keep the alignment correct. I don't think I fully understand the explanation. Can you point out the number(s) that's wrong, and how it should be corrected. (To which number does the -1 apply, and what units is it in?) Below, sda is internal, sdb is USB-connected. The latter causes a pair of messages when sdb2 is unlocked: device-mapper: table: 254:1: adding target device sdb2 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=33553920 device-mapper: table: 254:1: adding target device sdb2 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=33553920 What is it that "starts" at 33553920? $ lsblk -t NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME sda 0 4096 0 4096 512 1 cfq 128 128 0B ├─sda1 0 4096 0 4096 512 1 cfq 128 128 0B ├─sda2 0 4096 0 4096 512 1 cfq 128 128 0B ├─sda3 0 4096 0 4096 512 1 cfq 128 128 0B ├─sda4 0 4096 0 4096 512 1 cfq 128 128 0B ├─sda5 0 4096 0 4096 512 1 cfq 128 128 0B ├─sda6 0 4096 0 4096 512 1 cfq 128 128 0B ├─sda7 0 4096 0 4096 512 1 cfq 128 128 0B ├─sda8 0 4096 0 4096 512 1 cfq 128 128 0B │ └─swanhome 0 4096 0 4096 512 1 128 128 0B ├─sda9 0 4096 0 4096 512 1 cfq 128 128 0B ├─sda10 0 4096 0 4096 512 1 cfq 128 128 0B ├─sda11 0 4096 0 4096 512 1 cfq 128 128 0B ├─sda12 0 4096 0 4096 512 1 cfq 128 128 0B ├─sda13 0 4096 0 4096 512 1 cfq 128 128 0B └─sda14 0 4096 0 4096 512 1 cfq 128 128 0B sdb 0 4096 33553920 4096 512 1 cfq 128 128 32M ├─sdb1 0 4096 33553920 4096 512 1 cfq 128 128 32M └─sdb2 0 4096 33553920 4096 512 1 cfq 128 128 32M └─luks-0229da67-… -1 4096 0 4096 512 1 128 128 0B $ Here's the partitioning of these disks: $ sudo gdisk -l /dev/sda GPT fdisk (gdisk) version 1.0.1 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Disk /dev/sda: 976773168 sectors, 465.8 GiB Logical sector size: 512 bytes Disk identifier (GUID): 2653F13F-2CD0-406F-B004-6AFFDBE18127 Partition table holds up to 128 entries First usable sector is 34, last usable sector is 976773134 Partitions will be aligned on 2048-sector boundaries Total free space is 4077 sectors (2.0 MiB) Number Start (sector) End (sector) Size Code Name 1 2048 2050047 1000.0 MiB 2700 Basic data partition 2 2050048 2582527 260.0 MiB EF00 EFI system partition 3 2582528 4630527 1000.0 MiB ED01 Basic data partition 4 4630528 4892671 128.0 MiB 0C01 Microsoft reserved ... 5 4892672 347348991 163.3 GiB 0700 Basic data partition 6 347348992 429268991 39.1 GiB 8300 Linux-A 7 429268992 511188991 39.1 GiB 8300 Linux-B 8 511188992 883275775 177.4 GiB 8300 Linux-Home 9 883275776 883292159 8.0 MiB EF02 Linux-BIOS-Boot 10 883292160 892084223 4.2 GiB 8200 Linux-Swap 11 892086272 892803071 350.0 MiB 2700 12 892803072 894900223 1024.0 MiB 0700 Basic data partition 13 894900224 947329023 25.0 GiB 0700 Basic data partition 14 947329024 976773119 14.0 GiB 2700 Basic data partition $ $ sudo fdisk -l /dev/sdb Disk /dev/sdb: 931.5 GiB, 1000204885504 bytes, 1953525167 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 33553920 bytes Disklabel type: dos Disk identifier: 0x6bc6bcdc Device Boot Start End Sectors Size Id Type /dev/sdb1 2048 1302349823 1302347776 621G 7 HPFS/NTFS/exFAT /dev/sdb2 1302349824 1953521663 651171840 310.5G c W95 FAT32 (LBA) $ In case it helps: # cryptsetup luksFormat /dev/sdb2 […] # cryptsetup open --type luks /dev/sdb2 thequiz Enter passphrase for /dev/sdb2: # mkdosfs -v -i 20141210 -F 32 -n quiz02 /dev/mapper/thequiz mkfs.fat 4.1 (2017-01-24) mkfs.fat: warning - lowercase labels might not work properly with DOS or Windows /dev/mapper/thequiz has 255 heads and 63 sectors per track, hidden sectors 0x0000; logical sector size is 512, using 0xf8 media descriptor, with 651106305 sectors; drive number 0x80; filesystem has 2 32-bit FATs and 64 sectors per cluster. FAT size is 79488 sectors, and provides 10171051 clusters. There are 64 reserved sectors. Volume ID is 20141210, volume label quiz02 . # cryptsetup luksClose thequiz # Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Henrique de Moraes Holschuh <hmh@debian.org> |
|---|---|
| Date | 2018-07-28 22:30 +0200 |
| Subject | Re: kernel: device-mapper: table: 254:1: adding target device sda1 caused an alignment inconsistency |
| Message-ID | <wgE0F-1aq-1@gated-at.bofh.it> |
| In reply to | #198075 |
On Sat, 28 Jul 2018, David Wright wrote: > On Sat 28 Jul 2018 at 10:57:45 (-0300), Henrique de Moraes Holschuh wrote: > > On Sat, 28 Jul 2018, Rick Thomas wrote: > > > > rbthomas@small:~$ lsblk -t > > > > NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME > > > > sda 0 4096 33553920 4096 512 1 mq-deadline 60 128 0B > > > > `-sda1 0 4096 33553920 4096 512 1 mq-deadline 60 128 0B > > > > |-small-swap -1 4096 0 4096 512 1 128 128 32M > > > > |-small-root -1 4096 0 4096 512 1 128 128 32M > > > > `-small-home -1 4096 0 4096 512 1 128 128 32M > > > > mmcblk2 0 512 0 512 512 0 mq-deadline 128 128 0B > > > > |-mmcblk2p1 0 512 0 512 512 0 mq-deadline 128 128 0B > > > > `-mmcblk2p2 0 512 0 512 512 0 mq-deadline 128 128 0B > > > > rbthomas@small:~$ > > > > > > Note the alignment values of “-1” for the lvm entries but not for the GPT partition or the whole disk. > > > Why do you suppose that is? > > > > Keep in mind that you *offset*-align the outer container *only*, and then inside > > you just keep the size alignment. > > > > So, the above ensures correct use of the partitions even if sda1 is > > unaligned. > > > > If you offset-align sda1 to -1, everything inside it should have an offset of > > zero to keep the alignment correct. > > I don't think I fully understand the explanation. Can you point out > the number(s) that's wrong, and how it should be corrected. There is nothing wrong on the table above as far as I can tell, *assuming* the device does need the -1 alignment. Since sda1 isn't aligned, everything inside it at the first level must be (and is) aligned at -1 to compensate. Where sda1 aligned at -1, nothing inside it should be, as sda1 would already provide the required alignemnt to anything inside it. > (To which number does the -1 apply, and what units is it in?) It applies to whatever line it is listed, and it is in "host-side sectors" (512 bytes in this case), where "host" is "your computer" as opposed to "the HDD". No idea why your USB-connected HDD is causing the warnings. I didn't think there were still devices in the market with that dreadful "windows workaround" (which not even windows want, nowadays)... but USB-connected HDDs are *always* suspect of insanity caused by crap protocol bridges, so YMMV. -- Henrique Holschuh
[toc] | [prev] | [next] | [standalone]
| From | Rick Thomas <rbthomas@pobox.com> |
|---|---|
| Date | 2018-07-29 00:30 +0200 |
| Message-ID | <wgFSO-2jf-5@gated-at.bofh.it> |
| In reply to | #198077 |
On Jul 28, 2018, at 1:28 PM, Henrique de Moraes Holschuh <hmh@debian.org> wrote:
> On Sat, 28 Jul 2018, David Wright wrote:
>> On Sat 28 Jul 2018 at 10:57:45 (-0300), Henrique de Moraes Holschuh wrote:
>>> On Sat, 28 Jul 2018, Rick Thomas wrote:
>>>>> rbthomas@small:~$ lsblk -t
>>>>> NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME
>>>>> sda 0 4096 33553920 4096 512 1 mq-deadline 60 128 0B
>>>>> `-sda1 0 4096 33553920 4096 512 1 mq-deadline 60 128 0B
>>>>> |-small-swap -1 4096 0 4096 512 1 128 128 32M
>>>>> |-small-root -1 4096 0 4096 512 1 128 128 32M
>>>>> `-small-home -1 4096 0 4096 512 1 128 128 32M
>>>>> mmcblk2 0 512 0 512 512 0 mq-deadline 128 128 0B
>>>>> |-mmcblk2p1 0 512 0 512 512 0 mq-deadline 128 128 0B
>>>>> `-mmcblk2p2 0 512 0 512 512 0 mq-deadline 128 128 0B
>>>>> rbthomas@small:~$
>>>>
>>>> Note the alignment values of “-1” for the lvm entries but not for the GPT partition or the whole disk.
>>>> Why do you suppose that is?
>>>
>>> Keep in mind that you *offset*-align the outer container *only*, and then inside
>>> you just keep the size alignment.
>>>
>>> So, the above ensures correct use of the partitions even if sda1 is
>>> unaligned.
>>>
>>> If you offset-align sda1 to -1, everything inside it should have an offset of
>>> zero to keep the alignment correct.
>>
>> I don't think I fully understand the explanation. Can you point out
>> the number(s) that's wrong, and how it should be corrected.
>
> There is nothing wrong on the table above as far as I can tell,
> *assuming* the device does need the -1 alignment. Since sda1 isn't
> aligned, everything inside it at the first level must be (and is)
> aligned at -1 to compensate.
>
> Where sda1 aligned at -1, nothing inside it should be, as sda1 would
> already provide the required alignemnt to anything inside it.
Thanks for the clarification, Henrique!
Let me see if I have this right…
1) If I had heeded the warning in “man pvcreate” and set up the physical volume with
pvcreate —dataalignmentoffset 7s /dev/sda
to accommodate the -1 offset (provided either by the drive itself or the USB enclosure it is in — we don’t know) then all the “-1”s in the above table would be “0”s and I would not be getting the error messages at boot time. Is this correct?
2) But as it is, I did not do that, so when I used vgcreate to make the volume group called “small”, it realized that the partition was out of alignment and compensated — thus causing the alignment of “-1” for all of the logical volumes. And, most importantly, therefor the logical volumes are, in fact, properly aligned and I can stop worrying. Furthermore, the warnings at boot time are just noting that an alignment of “-1” has been applied by the device-mapper and all is well. Is this correct?
3) Or are you saying that the messages are _not_ just warnings: I should go back and re-format the disk to use the “—dataalignmentoffset 7s” option. (I can do this if I do it soon. I don’t have much data on the disk yet.)
Thanks,
Rick
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2018-07-29 17:20 +0200 |
| Subject | Re: kernel: device-mapper: table: 254:1: adding target device sda1 caused an alignment inconsistency |
| Message-ID | <wgVEe-3Ns-13@gated-at.bofh.it> |
| In reply to | #198078 |
On Sat 28 Jul 2018 at 15:23:48 (-0700), Rick Thomas wrote:
>
> On Jul 28, 2018, at 1:28 PM, Henrique de Moraes Holschuh <hmh@debian.org> wrote:
>
> > On Sat, 28 Jul 2018, David Wright wrote:
> >> On Sat 28 Jul 2018 at 10:57:45 (-0300), Henrique de Moraes Holschuh wrote:
> >>> On Sat, 28 Jul 2018, Rick Thomas wrote:
> >>>>> rbthomas@small:~$ lsblk -t
> >>>>> NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME
> >>>>> sda 0 4096 33553920 4096 512 1 mq-deadline 60 128 0B
> >>>>> `-sda1 0 4096 33553920 4096 512 1 mq-deadline 60 128 0B
> >>>>> |-small-swap -1 4096 0 4096 512 1 128 128 32M
> >>>>> |-small-root -1 4096 0 4096 512 1 128 128 32M
> >>>>> `-small-home -1 4096 0 4096 512 1 128 128 32M
> >>>>> mmcblk2 0 512 0 512 512 0 mq-deadline 128 128 0B
> >>>>> |-mmcblk2p1 0 512 0 512 512 0 mq-deadline 128 128 0B
> >>>>> `-mmcblk2p2 0 512 0 512 512 0 mq-deadline 128 128 0B
> >>>>> rbthomas@small:~$
> >>>>
> >>>> Note the alignment values of “-1” for the lvm entries but not for the GPT partition or the whole disk.
> >>>> Why do you suppose that is?
> >>>
> >>> Keep in mind that you *offset*-align the outer container *only*, and then inside
> >>> you just keep the size alignment.
> >>>
> >>> So, the above ensures correct use of the partitions even if sda1 is
> >>> unaligned.
> >>>
> >>> If you offset-align sda1 to -1, everything inside it should have an offset of
> >>> zero to keep the alignment correct.
> >>
> >> I don't think I fully understand the explanation. Can you point out
> >> the number(s) that's wrong, and how it should be corrected.
> >
> > There is nothing wrong on the table above as far as I can tell,
> > *assuming* the device does need the -1 alignment. Since sda1 isn't
> > aligned, everything inside it at the first level must be (and is)
> > aligned at -1 to compensate.
> >
> > Where sda1 aligned at -1, nothing inside it should be, as sda1 would
> > already provide the required alignemnt to anything inside it.
>
>
> Thanks for the clarification, Henrique!
Well, it didn't clarify much for me, but my case is different as I'm
only using LUKS and not LVM. More interesting to me than
https://unix.stackexchange.com/questions/340484/device-mapper-table-alignment-inconsistency
is
https://unix.stackexchange.com/questions/421587/dmsetup-luksformat-creating-an-alignment-inconsistency
which seems AIUI to put the prime cause on the interaction of the
drive and the kernel in producing the number 33553920 which is
garbage, and the blame on LUKS for using this number without
flagging the fact that it looks suspect (yielding an unaligned
"payload") and alerting the user to this fact on standard error.
> Let me see if I have this right…
>
> 1) If I had heeded the warning in “man pvcreate” and set up the physical volume with
> pvcreate —dataalignmentoffset 7s /dev/sda
> to accommodate the -1 offset (provided either by the drive itself or the USB enclosure it is in — we don’t know) then all the “-1”s in the above table would be “0”s and I would not be getting the error messages at boot time. Is this correct?
Knowing nothing about pvcreate, I can't comment on whether the fix is
correct. However, I don't understand what you mean by "accommodate
the -1 offset" because the partition itself looks aligned to me:
sda1 0 4096 33553920 4096 512 1 mq-deadline 60 128 0B
> 2) But as it is, I did not do that, so when I used vgcreate to make the volume group called “small”, it realized that the partition was out of alignment and compensated — thus causing the alignment of “-1” for all of the logical volumes. And, most importantly, therefor the logical volumes are, in fact, properly aligned and I can stop worrying. Furthermore, the warnings at boot time are just noting that an alignment of “-1” has been applied by the device-mapper and all is well. Is this correct?
I don't think the partition is unaligned.
> 3) Or are you saying that the messages are _not_ just warnings: I should go back and re-format the disk to use the “—dataalignmentoffset 7s” option. (I can do this if I do it soon. I don’t have much data on the disk yet.)
If that is the correct fix, you might as well do it at this stage.
I can't judge whether my case has led to performance degradation
but as mine has 2GB of backup in just two directories, recreating
the data is a two-minute job.
So here is my understanding of the simple LUKS case which I would
welcome criticisms of.
$ lsblk -t
NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME
[…]
├─sda8 0 4096 0 4096 512 1 cfq 128 128 0B
│ └─swanhome 0 4096 0 4096 512 1 128 128 0B
[…]
No problem here where OPT-IO == 0.
[…]
sdb 0 4096 33553920 4096 512 1 cfq 128 128 32M
├─sdb1 0 4096 33553920 4096 512 1 cfq 128 128 32M
└─sdb2 0 4096 33553920 4096 512 1 cfq 128 128 32M
└─luks-0229da67-… -1 4096 0 4096 512 1 128 128 0B
AIUI 33553920 is the maximum supported by USB transfers, but because
33553920/4096 is 8191.875 it is unlikely to be more optimal than, say,
4096*4096 which is 16777216, so 33553920 is garbage. Not LUKS's fault.
However, LUKS uses this number to calculate a "payload" offset
without any sanity-checking and without flagging the resulting
alignment offset and this is IMHO a bug in LUKS. (Here's cryptsetup
at work, as I elided it in my previous post.)
# cryptsetup luksFormat /dev/sdb2
WARNING!
========
This will overwrite data on /dev/sdb2 irrevocably.
Are you sure? (Type uppercase yes): YES
Enter passphrase:
Verify passphrase:
# cryptsetup open --type luks /dev/sdz9 thequiz
Enter passphrase for /dev/sdb2:
#
No indication of any problem.
Apparently the workaround is to specify
cryptsetup luksFormat […] --align-payload <N>
where N can be as low as 8, I read, but defaults to 2048. man cryptsetup:
--align-payload <number of 512 byte sectors>
Align payload at a boundary of value 512-byte sectors.
This option is relevant for luksFormat.
If not specified, cryptsetup tries to use the topology info
provided by kernel for the underlying device to get optimal
alignment. If not available (or the calculated value is a
multiple of the default) data is by default aligned to a 1MiB
boundary (i.e. 2048 512-byte sectors).
For a detached LUKS header this option specifies the offset
on the data device. See also the --header option.
I have no idea what the payload is. The only other mention is in
the --header option (for a "detached" LUKS header) where it says:
If used with luksFormat, the --align-payload option is taken as
absolute sector alignment on ciphertext device and can be zero.
which doesn't cast a lot of light.
Cheers,
David.
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.user
csiph-web