☰

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

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 /パーティションを生成する可能性があります。関連問題/修正事項：

答え2

同盟を結ぶドライブを最適に使用してください。ソフトウェアでこのエラーが発生し、大きなキャッシュを使用して補償することがあります。確認してください。

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

再フォーマットする必要がある問題（GPT / LVMレイヤーかもしれません）を解決するには、pvcreateの--dataalignmentと--dataalignmentoffsetを確認してください。

答え3

説明する

最初の値は、ターゲットデバイス（上）の最初のLVの最初のPEのオフセットstart=です。33553920/dev/sdb2

これは次のように確認できます。

sudo pvs -o +pe_start --units b

VGには2つのLV（およびLV）が含まれているため、別のstart=重複値があります。なぜそれぞれが重複するのかわかりません。sdb2usb-eMMC_backupusb-ark

理由

ソートの不一致は、次のように分割できpe_startないために存在しますPHY-SEC。

lsblk -t /dev/sdb

PHY-SEC4096 で、33553920%4096 != 0 です。

pe_startソートされていない場合（デフォルトのPEサイズは4MiB）、VG内のすべてのLVが正しくソートされません。

解決する

pe_startディスクセクタサイズに均等に分割できるVGを作成する必要があります。

渡される値--dataalignment 1mは= 1048576B = 1MiBvgcreateです。pe_start

それでも受け取ったらどうなりますかalignment inconsistency？

プライマリパーティションがソートされていると仮定すると、ソートメッセージが正しくありませんが、引き続き生成される可能性があります。バラよりこの回答特にUSB接続SATA（UAS）を使用するときの考えられる原因と解決策について学びます。

関連情報