web-dev-qa-db-ja.com

dmsetupluksFormatが配置の不整合を作成する

新しくフォーマットされたLUKSボリュームのロックを解除すると、カーネルログに警告が表示されました。

kernel: device-mapper: table: 253:14: adding target device sdk1 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=33553920

別の質問によると、 誤った警告が発生する可能性があります なので、本当の警告であることを確認しました：33553920は4096で割り切れません。さらに、luksDumpを使用して確認しました：

cryptsetup luksDump /dev/sdk1  | grep 'Payload offset'
Payload offset: 65535

これは8の倍数ではありません（4096÷512 = 8）

lsblk -t /dev/sdkLinuxがアライメント要件を認識していることを確認します。

NAME             ALIGNMENT MIN-IO   OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE  RA WSAME
sdk                      0   4096 33553920    4096     512    1 cfq       128 128   32M
└─sdk1                   0   4096 33553920    4096     512    1 cfq       128 128   32M

dmsetupは、アライメント自体を処理するように文書化されていますが、なぜそれがミスアライメントを作成したのですか？そして、問題を回避するためのluksFormatへの引数はありますか？

linuxencryptiondisklukscryptsetup
5
derobert

Dmsetupは、実際の物理ブロックサイズの倍数であることを確認する手間をかけずに、最適なI/Oサイズからアライメントを計算しているようです。誤った警告の質問で述べたように、この最適なI/Oサイズは、USBの制約のために理にかなっています。

したがって、解決策は簡単です。検出された値を上書きするには、--align-payloadを使用します。値8が機能するはずです（そして可能な限り最小のヘッダーを生成します）。 cryptsetupが判別できない場合のデフォルトは2048として文書化されています。したがって、デフォルトを使用しました。

cryptsetup luksFormat /dev/sdk1 --align-payload 2048 --verify-passphrase --hash sha512 -s 512

その後、ペイロードオフセットは4096（luksDumpから）になり、カーネル警告が引き続き生成されます。

kernel: device-mapper: table: 253:14: adding target device sdk1 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=2097152

...しかし、2097152は4096で割り切れるので、他の質問で言及されている誤った警告です。これで問題は解決しました。

8
derobert