Re: misaligned ending sector, 4096-byte luks sector size can't be used

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 24/01/2022 18:07, Chris Murphy wrote:
Hi,

cryptsetup-2.4.3-1.fc36.x86_64

On 512-byte logical sector size, 4096-byte physical sector size
drives, cryptsetup luksFormat uses a 4096-byte LUKS sector size except
when there's an unaligned last sector in a partition, i.e. the
partition ends within a 4096-byte physical sector. Unfortunately this
is pretty common due to the backup GPT, which makes the "last usable"
sector, unaligned. gdisk, fdisk, and parted can all run into this
problem. I can't really tell if this was ever considered by UEFI/GPT
spec writers. The backups GPT is 33 LBAs in size. So it's always
4096-byte unaligned.

All the sectors in the partition are 4096-byte aligned except the last
one.

And IMO this is the bug in partition tools. We already discussed this with
util-linux (and fdisk) maintainer, I am not sure if they will fix that.

But anything else would be a horrible hack. If the device is not aligned
to requested sector length (usually 4k), then it cannot be used with that
sector size.

The whole idea of misaligned backup GPT at the end of device is broken.
We should not follow that with adding hacks when the easy solution
is just to align a partition properly.

Years ago there was a general agreement to align partition start to 1 MiB
offset, I think we should do the same for the partition length.

Therefore it seems suboptimal to fall back to 512-byte LUKS
sector size, or for luksFormat --sector-size 4096 to fail. Is there a
way for cryptsetup to just map out the dangling 1-7 512-byte sectors
at the end? They are useless anyway in this case, but the partitioning
tools aren't in a position to know the use case. The last 1-7 sectors
are legitimately individually addressable so it's not incorrect for
the partitioning tool to include them in the last partition on the
device.

The default is to not store device length in LUKS header - so it follows
underlying device resize.
If you set sector size to 4k, then the unaligned sectors are no longer
"legitimately" addressable (dm-crypt will set 4k as "physical" sector,
IOW as atomic unit of the device). I understand that some filesystems use
hacks to ignore this, but it is really not a system solution.

Milan
_______________________________________________
dm-crypt mailing list -- dm-crypt@xxxxxxxx
To unsubscribe send an email to dm-crypt-leave@xxxxxxxx



[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux