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, um falso aviso é possível , então confirmei que é um aviso verdadeiro: 33553920 não é divisível por 4096. Usei ainda luksDump para confirmar:
cryptsetup luksDump /dev/sdk1 | grep 'Payload offset'
Payload offset: 65535
que não é múltiplo de 8 (4096 ÷ 512 = 8)
lsblk -t /dev/sdkconfirma 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
dmsetup está documentado para lidar com o próprio alinhamento, por que criou um desalinhamento? E existem argumentos para luksFormat para evitar o problema?
Parece que o dmsetup calcula seu alinhamento a partir do tamanho ideal de E/S, sem se preocupar em verificar se isso é realmente um múltiplo do tamanho do bloco físico. Conforme mencionado na pergunta do falso aviso, esse tamanho ideal de E/S faz sentido devido às restrições do USB.
Portanto, a solução é simples: use
--align-payloadpara substituir o valor detectado. Um valor de 8 deve funcionar (e produzir o menor cabeçalho possível); o padrão quando o cryptsetup não pode dizer é documentado como 2048. Então, fui com o padrão:Depois disso, o deslocamento da carga útil agora é 4096 (de luksDump) e um aviso do kernel ainda é produzido:
... mas 2097152 é divisível por 4096, então esse é o falso aviso mencionado na outra pergunta. Então o problema está resolvido.