Re: Alignment issue with 4K disk

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

 



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




[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