新しくフォーマットされた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/sdk
Linuxがアライメント要件を認識していることを確認します。
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への引数はありますか?
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で割り切れるので、他の質問で言及されている誤った警告です。これで問題は解決しました。