Inconsistência no alinhamento da tabela do mapeador de dispositivos

Question

No diário, estou recebendo frases como:

Jan 27 18:23:08 tara kernel: device-mapper: table: 254:2: adding target device sdb2 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=33553920
Jan 27 18:23:08 tara kernel: device-mapper: table: 254:2: adding target device sdb2 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=33553920
Jan 27 18:23:08 tara kernel: device-mapper: table: 254:3: adding target device sdb2 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=34393292288
Jan 27 18:23:08 tara kernel: device-mapper: table: 254:3: adding target device sdb2 caused an alignment inconsistency: physical_block_size=4096, logical_block_size=512, alignment_offset=0, start=34393292288

O que exatamente está alinhado incorretamente aqui? Posso torná-lo consistente?

Mais informações:

[ravi@tara ~]$ uname -a
Linux tara 4.8.17-1-MANJARO #1 SMP PREEMPT Mon Jan 9 10:24:58 UTC 2017 x86_64 GNU/Linux
[ravi@tara ~]$ lsblk
NAME                MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                   8:0    0  3.7T  0 disk
sdb                   8:16   0  3.7T  0 disk
├─sdb1                8:17   0  200M  0 part
└─sdb2                8:18   0  3.7T  0 part
  ├─usb-eMMC_backup 254:2    0   32G  0 lvm
  └─usb-ark         254:3    0  3.6T  0 lvm  /ark
sdc                   8:32   1  7.5G  0 disk
└─sdc1                8:33   1  7.5G  0 part
mmcblk0             179:0    0 29.1G  0 disk
├─mmcblk0p1         179:1    0  200M  0 part /mnt/esp
└─mmcblk0p2         179:2    0 28.9G  0 part
  ├─lvm-root        254:0    0   24G  0 lvm  /
  └─lvm-swap        254:1    0  4.9G  0 lvm  [SWAP]
mmcblk0boot0        179:8    0    4M  1 disk
mmcblk0boot1        179:16   0    4M  1 disk
mmcblk0rpmb         179:24   0    4M  0 disk
[ravi@tara ~]$

    

Answer 1

O aviso indica que a partição e o dispositivo LVM podem estar desalinhados, conforme definido pelas verificações em blk_stack_limits . Você pode examinar os valores da saída de lsblk -t /dev/sdb e verificar os tipos de desalinhamentos capturados em blk_stack_limits (por exemplo, físico múltiplo de tamanho de bloco lógico, opt e min I / O são múltiplos de tamanho de bloco físico etc.)

A conclusão de Sven Eschenberg em um longo tópico na lista de dm-cripta foi que algumas dessas verificações podem gerar avisos incorretos. Em particular, se sdb for um disco USB, o tamanho ideal de E / S pode não ser um múltiplo do tamanho do setor físico (por exemplo, tenho um disco USB 4k que relatórios physical_block_size 4.096 e optimal_io_size 33,553,920). Esses valores estão corretos (conforme relatado pela unidade), plausíveis (devido a restrições USB) e não são baseados em nenhum dos parâmetros do mapeador de dispositivos.

O problema neste caso é que a lógica em blk_stack_limits assume que o tamanho de E / S ideal será um múltiplo do tamanho do setor físico, o que não é verdadeiro para alguns dispositivos. Se este for o seu caso, você pode ignorar com segurança o aviso.

    

Answer 2

Alinhamento garante o uso ideal de sua unidade, às vezes o software faz isso errado e compensa usando um cache maior, marque

cat /sys/block/sd?/queue/optimal_io_size

para corrigir, você tem que re-formatar (provavelmente ambas as camadas GPT / LVM) olhe para --dataalignment e --dataalignmentoffset de pvcreate