dmsetup luksFormat criando uma inconsistência de alinhamento

Question

Ao desbloquear um volume LUKS recém-formatado, recebi um aviso no log do kernel:

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

De acordo com outra pergunta, uma possível aviso falso , então eu confirmou que é um verdadeiro aviso: 33553920 não é divisível por 4096. Eu também usei luksDump para confirmar:

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

que não é um múltiplo de 8 (4096 ÷ 512 = 8)

lsblk -t /dev/sdk confirma que o Linux está ciente dos requisitos de alinhamento:

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

O dmsetup é documentado para lidar com o alinhamento em si, por que ele criou um desalinhamento? E há argumentos para luksFormat para evitar o problema?

    

Answer 1

Parece que o dmsetup calcula seu alinhamento a partir do tamanho ideal de E / S, sem se preocupar em verificar se esse é realmente um múltiplo do tamanho do bloco físico. Como mencionado na pergunta de aviso falso, esse tamanho ideal de E / S faz sentido devido a restrições USB.

Portanto, a solução é simples: use --align-payload para substituir o valor detectado. Um valor de 8 deve funcionar (e produzir o menor cabeçalho possível); o padrão quando cryptsetup não pode dizer é documentado como 2048. Então eu fui com o padrão:

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

Depois disso, o deslocamento da carga útil agora é 4096 (de luksDump), e um aviso de kernel ainda é produzido:

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

... mas 2097152 é divisível por 4096, então esse é o aviso falso mencionado na outra pergunta. Então o problema está resolvido.