Hi Eugen,
Ignore my previous mail, don't ask me why, but I looked at the size of
the mapping. The offset is actually 256 sectors which is fine and should
not be misaligned. VeraCrypt uses 128KByte as offset, which indeed is
256 sectors and should be 4K aligned if the partition is.
The output of lsblk suggests that the partition itself is aligned (and
the output from fdisk seems to support this).
Anyhow, it is the device mapper, in dm-table.c that claims the
misalignment. Basicly geometry and io limits are compared and checked
during stacking one of the tests is:
-- Optimal I/O a multiple of the physical block size?
Which is triggered (look at the optimal IO size.
My personal opinion is: The test is semantically wrong in different
aspects. May I ask what drive you are using and what interface it uses?
Regards
-Sven
Am 10.01.2016 um 02:14 schrieb Sven Eschenberg:
Hi Eugen,
Indeed the optimal IO value (on sdc) seems a little weird. Yet this
should not create any alignment warnings.
zuluCrypt-1001-NAAN-sdc4-1790378342: 0 11406264975 - Now this is not 4k
aligned (sectors must be divideable by 8 to be 4k aligned). Indeed the
encrypted payload should start at 11406264976 sectors, so there is a -1
sector misalignment (See lsblk output saying so). VeraCrypt did not
properly align the payload when the container was created, I assume.
Regards
-Sven
Am 10.01.2016 um 01:25 schrieb Eugen Rogoza:
Hi,
Reporter should paste output of "lsblk -t" with device activated to
check what underlying
device report alignment limits are violated in storage stack).
I am the reporter and the output of 'lsblk -t' with encrypted
partition mounted is below. sda2 is the one that works fine, sdc4 is
the one that throws alignment warnings.
root@nuc:~> 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
└─zuluCrypt-1001-NAAN-sda2-4071757814 0 4096 0
4096 512 1 128 128 0B
sdb 0 512 0
512 512 0 noop 128 128 0B
├─sdb1 0 512 0
512 512 0 noop 128 128 0B
├─sdb2 0 512 0
512 512 0 noop 128 128 0B
├─sdb3 0 512 0
512 512 0 noop 128 128 0B
└─sdb4 0 512 0
512 512 0 noop 128 128 0B
sdc 0 4096 33553920
4096 512 1 cfq 128 128 32M
├─sdc1 0 4096 33553920
4096 512 1 cfq 128 128 32M
├─sdc2 0 4096 33553920
4096 512 1 cfq 128 128 32M
├─sdc3 0 4096 33553920
4096 512 1 cfq 128 128 32M
└─sdc4 0 4096 33553920
4096 512 1 cfq 128 128 32M
└─zuluCrypt-1001-NAAN-sdc4-1790378342 -1 4096 0
4096 512 1 128 128 0B
That is indeed true and further info including 'dmsetup table' will be
necessary to tell what is really going on.
Output below. Again, sdc4 is the problematic one.
root@nuc:~> dmsetup table
zuluCrypt-1001-NAAN-sdc4-1790378342: 0 11406264975 crypt
aes-xts-plain64
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
256 8:36 256
zuluCrypt-1001-NAAN-sda2-4071757814: 0 1324371456 crypt
aes-xts-plain64
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
256 8:2 256
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
