Alignment issue with 4K disk

dm-crypt Yves-Alexis Perez 4 participants 9 messages Jan 4, 2016 – Jan 9, 2016

Share & tools

Yves-Alexis Perez

author

2016-01-04 21:31 UTC #0 lore raw

Hi,

I'm trying to setup an encrypted volume on an external disk which has 4k physical sector size (with 512b logical sector size).

I've used various parted option (-a none / minimal / optimal) and various -- align-payload options to cryptsetup, but everytime I luksOpen the container, I get a kernel log with:

janv. 04 22:25:04 scapa kernel: device-mapper: table: 253:4: adding target device sdb1 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=4194304

(argument for start= changes for different values of the --align-payload)

I'm not sure it's really serious, but any idea how to fix that?

Regards,

Signature · 1 line

Yves-Alexis

Sven Eschenberg

2016-01-04 21:54 UTC #1 lore raw

Hi,

start=4194304 -> assumind this is in 512 byte blocks, the start sector is aligned to MByte boundary and thus 4k boundary.

Anyway, if your device only has one partition which is encrypted with dm-crypt, set it up to start at sector 2048 (which should be default for parted, fdisk and so on). Pass align-payload 2048 during creation of the LUKS header, which will give you an MByte boundary and should always be okay.

If the kernel still complains, then something else might be going wrong.

Regards

-Sven

Am 04.01.2016 um 22:31 schrieb Yves-Alexis Perez:

Quoted 24 lines

Hi,
I'm trying to setup an encrypted volume on an external disk which has 4k physical sector size (with 512b logical sector size).
I've used various parted option (-a none / minimal / optimal) and various -- align-payload options to cryptsetup, but everytime I luksOpen the container, I get a kernel log with:
janv. 04 22:25:04 scapa kernel: device-mapper: table: 253:4: adding target device sdb1 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=4194304
(argument for start= changes for different values of the --align-payload)
I'm not sure it's really serious, but any idea how to fix that?
Regards,
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt

Yves-Alexis Perez

author

2016-01-04 22:20 UTC #2 lore raw

Quoted 5 lines · Sven Eschenberg

Hi,
start=4194304 -> assumind this is in 512 byte blocks, the start sector is aligned to MByte boundary and thus 4k boundary.

Quoted 7 lines

Anyway, if your device only has one partition which is encrypted with dm-crypt, set it up to start at sector 2048 (which should be default for parted, fdisk and so on). Pass align-payload 2048 during creation of the LUKS header, which will give you an MByte boundary and should always be okay.
If the kernel still complains, then something else might be going wrong.

Right now I have:

root@scapa:~# lsblk -o +ALIGNMENT /dev/sdc
NAME             MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT        ALIGNMENT
sdc                8:32   0 931.5G  0 disk                            0
└─sdc1             8:33   0 931.5G  0 part                          512
  └─scapa-backup 253:4    0 931.4G  0 crypt /mnt/scapa-backup        -1

And:

scapa-backup: 0 1953336209 crypt aes-xts-plain64 0000000000000000000000000000000000000000000000000000000000000000 0 8:33 65536

root@scapa:~# fdisk -l /dev/sdc
Disk /dev/sdc: 931.5 GiB, 1000204886016 bytes, 1953525168 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: gpt
Disk identifier: EBA98857-89BA-4B2C-8366-4A77A527A8E0

Device Start End Sectors Size Type /dev/sdc1 65535 1953467279 1953401745 931.5G Linux filesystem

Partition 1 does not start on physical sector boundary.

[I'm a bit concerned with that, but since I'm using a GPT and not MBR it might be related]

root@scapa:~# gdisk -l /dev/sdc
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/sdc: 1953525168 sectors, 931.5 GiB Logical sector size: 512 bytes
Disk identifier (GUID): EBA98857-89BA-4B2C-8366-4A77A527A8E0 Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1953525134 Partitions will be aligned on 8-sector boundaries Total free space is 123356 sectors (60.2 MiB)

Number Start (sector) End (sector) Size Code Name 1 65535 1953467279 931.5 GiB 8300 scapa-backup

Regards,

Signature · 1 line

Yves-Alexis

Sven Eschenberg

2016-01-04 22:41 UTC #3 lore raw

The Startsector of the Partition should NEVER be odd, rather even. 65536 would be fine, that's why lsblk gives an alignment of -1 for scapa-backup I guess.

It does not matter if you use MBR or GPT, well, not too much for this matter. The GPT is 34 LBA blocks (of 512 bytes). It can possibly be longer to host more than 128 Partition entries, but no way close to 2048 which would resemble 1MByte. So 2048s would be a good place to start your partition. It is aligned to 1 MByte, as well as 4KByte ... it even is aligned to all major SSD Page-Sizes and SSD Erase-Block-Sizes.

Anyhow you either need to align the start of your partition or you'll have an extremly hard time aligning the dm-crypt offset manually at the right place.

Regards

-Sven

P.S.: If you still have a chance to change things, better do it now!

Am 04.01.2016 um 23:20 schrieb Yves-Alexis Perez:

Quoted 73 lines · Sven Eschenberg

Quoted 5 lines
Hi,
start=4194304 -> assumind this is in 512 byte blocks, the start sector is aligned to MByte boundary and thus 4k boundary.
Quoted 7 lines
Anyway, if your device only has one partition which is encrypted with dm-crypt, set it up to start at sector 2048 (which should be default for parted, fdisk and so on). Pass align-payload 2048 during creation of the LUKS header, which will give you an MByte boundary and should always be okay.
If the kernel still complains, then something else might be going wrong.
Right now I have:
root@scapa:~# lsblk -o +ALIGNMENT /dev/sdc
NAME             MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT        ALIGNMENT
sdc                8:32   0 931.5G  0 disk                            0
└─sdc1             8:33   0 931.5G  0 part                          512
   └─scapa-backup 253:4    0 931.4G  0 crypt /mnt/scapa-backup        -1
And:
scapa-backup: 0 1953336209 crypt aes-xts-plain64 0000000000000000000000000000000000000000000000000000000000000000 0 8:33 65536
root@scapa:~# fdisk -l /dev/sdc
Disk /dev/sdc: 931.5 GiB, 1000204886016 bytes, 1953525168 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: gpt
Disk identifier: EBA98857-89BA-4B2C-8366-4A77A527A8E0
Device Start End Sectors Size Type
/dev/sdc1 65535 1953467279 1953401745 931.5G Linux filesystem
Partition 1 does not start on physical sector boundary.
[I'm a bit concerned with that, but since I'm using a GPT and not MBR it might be related]
root@scapa:~# gdisk -l /dev/sdc
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/sdc: 1953525168 sectors, 931.5 GiB Logical sector size: 512 bytes
Disk identifier (GUID): EBA98857-89BA-4B2C-8366-4A77A527A8E0 Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1953525134 Partitions will be aligned on 8-sector boundaries Total free space is 123356 sectors (60.2 MiB)
Number Start (sector) End (sector) Size Code Name
    1           65535      1953467279   931.5 GiB   8300  scapa-backup
Regards,
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt

Sven Eschenberg

2016-01-04 23:02 UTC #4 lore raw

In reply to Yves-Alexis Perez

Hi Alexis,

I stumbled over this line:

I/O size (minimum/optimal): 4096 bytes / 33553920 bytes

The latter resembles 65535 sectors (512 Byte logical ones), which explains why the automated alignment was done at sector 65535. This value seems extremely weird though.

You said the drive was external, connected how? USB maybe?

Can you take a look at hdparm -I /dev/sdc? Anything unusual there?

Regards

-Sven

Am 04.01.2016 um 23:20 schrieb Yves-Alexis Perez:

Quoted 73 lines · Sven Eschenberg

Quoted 5 lines
Hi,
start=4194304 -> assumind this is in 512 byte blocks, the start sector is aligned to MByte boundary and thus 4k boundary.
Quoted 7 lines
Anyway, if your device only has one partition which is encrypted with dm-crypt, set it up to start at sector 2048 (which should be default for parted, fdisk and so on). Pass align-payload 2048 during creation of the LUKS header, which will give you an MByte boundary and should always be okay.
If the kernel still complains, then something else might be going wrong.
Right now I have:
root@scapa:~# lsblk -o +ALIGNMENT /dev/sdc
NAME             MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT        ALIGNMENT
sdc                8:32   0 931.5G  0 disk                            0
└─sdc1             8:33   0 931.5G  0 part                          512
   └─scapa-backup 253:4    0 931.4G  0 crypt /mnt/scapa-backup        -1
And:
scapa-backup: 0 1953336209 crypt aes-xts-plain64 0000000000000000000000000000000000000000000000000000000000000000 0 8:33 65536
root@scapa:~# fdisk -l /dev/sdc
Disk /dev/sdc: 931.5 GiB, 1000204886016 bytes, 1953525168 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: gpt
Disk identifier: EBA98857-89BA-4B2C-8366-4A77A527A8E0
Device Start End Sectors Size Type
/dev/sdc1 65535 1953467279 1953401745 931.5G Linux filesystem
Partition 1 does not start on physical sector boundary.
[I'm a bit concerned with that, but since I'm using a GPT and not MBR it might be related]
root@scapa:~# gdisk -l /dev/sdc
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/sdc: 1953525168 sectors, 931.5 GiB Logical sector size: 512 bytes
Disk identifier (GUID): EBA98857-89BA-4B2C-8366-4A77A527A8E0 Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1953525134 Partitions will be aligned on 8-sector boundaries Total free space is 123356 sectors (60.2 MiB)
Number Start (sector) End (sector) Size Code Name
    1           65535      1953467279   931.5 GiB   8300  scapa-backup
Regards,
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt

Yves-Alexis Perez

author

2016-01-05 10:14 UTC #5 lore raw

Quoted 1 line · Sven Eschenberg

Hi Alexis,

(Yves-Alexis actually)

Quoted 10 lines

I stumbled over this line:
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
The latter resembles 65535 sectors (512 Byte logical ones), which explains why the automated alignment was done at sector 65535. This value seems extremely weird though.
You said the drive was external, connected how? USB maybe?

Yes. It's a Samsung T3 disk, so everything is integrated (disk+sata/usb3 adapter), not much chance I can do anything here.

I'll try to force the alignment to 2048s for part1 and see what happens.

Quoted 2 lines

Can you take a look at hdparm -I /dev/sdc? Anything unusual there?

I'll try tonight (I don't have it at hand).

Thanks for the pointers though.

Signature · 1 line

Yves-Alexis

.. ink ..

2016-01-07 18:01 UTC #6 lore raw

There is another (i think) related problem that was reported here[1]

Are these warnings serious or can they be ignored?

[1] https://github.com/mhogomchungu/zuluCrypt/issues/25

Quoted 34 lines · Yves-Alexis Perez

Quoted 1 line · Sven Eschenberg
Hi Alexis,
(Yves-Alexis actually)
Quoted 10 lines
I stumbled over this line:
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
The latter resembles 65535 sectors (512 Byte logical ones), which explains why the automated alignment was done at sector 65535. This value seems extremely weird though.
You said the drive was external, connected how? USB maybe?
Yes. It's a Samsung T3 disk, so everything is integrated (disk+sata/usb3 adapter), not much chance I can do anything here.
I'll try to force the alignment to 2048s for part1 and see what happens.
Quoted 2 lines
Can you take a look at hdparm -I /dev/sdc? Anything unusual there?
I'll try tonight (I don't have it at hand).
Thanks for the pointers though.
--
Yves-Alexis
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt

Milan Broz

2016-01-09 12:30 UTC #7 lore raw

Quoted 6 lines · .. ink ..

There is another (i think) related problem that was reported here[1]
Are these warnings serious or can they be ignored?
[1] https://github.com/mhogomchungu/zuluCrypt/issues/25

If I read this correctly, it s caused by mapping of an unaligned plaintext device-mapper device (unlocked VeraCrypt) to underlying partition.

That's a bug (or lack of proper alignment) inside VeraCrypt header or in GPT partitioning
- it should respect underlying device alignment while creating device/partition.

Anyway, I think the only consequence should be performance drop, it should still work.

Note that output from GPT says 512B while dm kernel message says 4k block... GPT should use 4k block as well.
Reporter should paste output of "lsblk -t" with device activated to check what underlying device report alignment limits are violated in storage stack).

We cannot do anything with it I guess, cryptsetup just activates what is written inside Veracrypt header using alignment limits reported by kernel.

Milan

Sven Eschenberg

2016-01-09 14:47 UTC #8 lore raw

Hi Milan,

Am 09.01.2016 um 13:30 schrieb Milan Broz:

Quoted 12 lines · .. ink ..

Quoted 6 lines
There is another (i think) related problem that was reported here[1]
Are these warnings serious or can they be ignored?
[1] https://github.com/mhogomchungu/zuluCrypt/issues/25
If I read this correctly, it s caused by mapping of an unaligned plaintext device-mapper device (unlocked VeraCrypt) to underlying partition.

Looks like it...

Quoted 10 lines

That's a bug (or lack of proper alignment) inside VeraCrypt header or in GPT partitioning
- it should respect underlying device alignment while creating device/partition.
Anyway, I think the only consequence should be performance drop, it should still work.
Note that output from GPT says 512B while dm kernel message says 4k block... GPT should use 4k block as well.
Reporter should paste output of "lsblk -t" with device activated to check what underlying device report alignment limits are violated in storage stack).

GPT fdisk claims 512 byte logical blocksize, which seems legit for a 512e drive. It even says that partitions should be aligned to 2048 sectors (which is MByte boundaries and 4k aligned). This seems all legit, as the GPT demands to be LBA aligned and 512e drives do indeed use a 512 byte sector addressing.

Even start=131072 is a multiple of 2048 and thus MByte aligned - It does indeed look a little odd.

Quoted 3 lines

We cannot do anything with it I guess, cryptsetup just activates what is written inside Veracrypt header using alignment limits reported by kernel.

That is indeed true and further info including 'dmsetup table' will be necessary to tell what is really going on.

Quoted 7 lines

Milan
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt

Regards

-Sven