Re: kernel: device-mapper: table: 254:1: adding target device sda1 caused an alignment inconsistency
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.
Reply to: