☰

デバイスマッパーテーブルのソートが一貫していない

tag-icon • tag-icon linux device-mapper
デバイスマッパーテーブルのソートが一貫していない

日誌で以下の内容を受け取りました。

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

これをどのように説明しますか？

  • ここでソートに正確に何の問題がありますか？
  • 数字はどこから来ますかstart=？

ソートを一貫させるにはどうすればよいですか？

追加情報：

[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 ~]$

ベストアンサー1

この警告は、スキャンで定義されているように、パーティションとLVMデバイスが正しく整列していない可能性があることを示します。blk_stack_limits。出力値を確認しlsblk -t /dev/sdb、キャプチャされたソート不良タイプを確認できますblk_stack_limits（たとえば、物理は論理ブロックサイズの倍数、opt、min I / Oは物理ブロックサイズの倍数など）。

2019-03-03 アップデート:@derobertがコメントで指摘したように、この場合警告は正しいです。 PV は物理ブロックサイズ 4,096 の倍数ではなくバイト 33,553,920 から始まります。この問題を解決するには、4,096の倍数で始まるようにPV /パーティションを移動または再生成する必要があります（たとえば、/またはに--dataalignment渡す）。vgcreatepvcreate--offsetcryptsetup

残念ながら、修正が開始された後も「一貫性のないソート」メッセージが印刷され続けます。 Sven Eschenbergは、dm-cryptリストの長い投稿で、これらのチェックの一部が誤った警告を生成する可能性があると結論付けました。 特にsdbUSBディスクの場合、最適なI / Oサイズは物理セクタサイズの倍数ではない可能性があります。たとえば、physical_block_size4,096とoptimal_io_size33,553,920を報告する4k USB3ディスクがあります。この値は正確であり（ドライブが報告したように）、合理的であり（USB制限のため）、デバイスマッパーパラメータに基づいていません。

問題は、ロジックでblk_stack_limits最適なI / Oサイズが物理セクタサイズの倍数であると仮定していますが、一部のデバイスではそうでないことです。これが唯一の問題であれば、警告を無視しても構いません。

2019-03-03 アップデート: 残念ながら、一部のツールは誤ってソートされたPV /パーティションを生成する可能性があります。関連問題/修正事項：

おすすめ記事