☰

LVMボリュームを0にする問題

tag-icon • tag-icon linux lvm dd
LVMボリュームを0にする問題

私のシステムには、eMMCデバイスに2つのLVMボリュームがあり、ボリュームの1つをゼロで埋めて「削除」しようとしています。 LVMを初めて使用するので、成功せずに試したことをお見せしましょう。

まず、私はいつもpvdisplay -mボリュームがどのように設定されているかを見ていきます。

# pvdisplay -m
  --- Physical volume ---
  PV Name               /dev/mmcblk0p2
  VG Name               vg0
  PV Size               3.42 GiB / not usable 3.00 MiB
  Allocatable           yes
  PE Size               4.00 MiB
  Total PE              876
  Free PE               776
  Allocated PE          100
  PV UUID               i2Abz2-4o2h-9hq4-Gk3h-b5SD-0r9M-7oDfh3

  --- Physical Segments ---
  Physical extent 0 to 49:
    Logical volume      /dev/vg0/volume_a
    Logical extents     0 to 49
  Physical extent 50 to 99:
    Logical volume      /dev/vg0/volume_b
    Logical extents     0 to 49
  Physical extent 100 to 875:
    FREE

これは簡単に見えます。

  • VGがあり、vg0
  • vg0PV 1個で構成されており、/dev/mmcblk0p2
  • PVは3.42GiBで、876個の4MiB PEに分かれています。
  • PE[0, 49]は最初のLVを保存し、volume_a
  • PE [50, 99]は2番目のLVを保存し、volume_b

volume_bこれを念頭に置いて、私はそれをゼロにしようとしましたdd。

# dd if=/dev/zero of=/dev/vg0/volume_b bs=1M count=200
201+0 records in
200+0 records out
209715200 bytes (210 MB, 200 MiB) copied, 17.2374 s, 12.2 MB/s

出力に基づいて、PE [50、99]（200M-400M）をゼロで埋める必要があるとしますpvdisplay -m。/dev/mmcblk0p2しかし、これが私が見るものです：

# hexdump /dev/mmcblk0p2 -s 200m
c800000 0000 0000 0000 0000 0000 0000 0000 0000
*
c900400 c800 0000 2000 0003 2800 0000 f0ad 0002
c900410 c7f5 0000 0001 0000 0000 0000 0000 0000

0はいくつかありますが、1MiBに固有のものです。その後、ランダムな数字でいっぱいになって再確認しました。

# dd if=/dev/urandom of=/dev/vg0/volume_b bs=1M count=200
200+0 records in
200+0 records out
209715200 bytes (210 MB, 200 MiB) copied, 99.9135 s, 2.1 MB/s
# hexdump /dev/mmcblk0p2 -s 200m
c800000 0000 0000 0000 0000 0000 0000 0000 0000
*
c900400 c800 0000 2000 0003 2800 0000 f0ad 0002
c900410 c7f5 0000 0001 0000 0000 0000 0000 0000

以前と同じで、私のdd通話は私の思うように進まないようです。私の仮定は、LVが/dev/vg0/volume_b「仮想」ブロックデバイスであり、ddここに書き込むと、LVMがそれを実際のブロック書き込みのために対応するPEにマップすることです。残念ながら、これは私が見るものと一致しません。

[編集1]確認してみると驚くhexdumpほど/dev/vg0/volume_bランダムなごみでいっぱいです。hexdump私はプロセス全体を認識し、データが保存されている場所を見つけるために使用/dev/mmcblk0p2しました。grep今はスムーズに進んでいますので更新されれば更新します。

[編集2]検索結果がありません。

ベストアンサー1

さらなるテストは、LVMとLinuxカーネルとの関係に問題があることを示しました。ディスクキャッシュに関連していると推測されますが、100％確実ではありません。これが私が見つけたものです：

まず、LVMボリュームにジャンクデータを書き込みます。

# dd if=/dev/urandom of=/dev/vg0/volume_b bs=1M count=1
1+0 records in
1+0 records out
1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.600447 s, 1.7 MB/s

その後、LVMボリュームを再読み込みしました。以下は、作成されたごみの一部です。

# hexdump /dev/vg0/volume_b -n 0x20
0000000 2358 898b a13b 8d94 39a1 bff6 8b38 79ec
0000010 9155 1202 ce46 938f 49dc 7687 f804 bf13
0000020

しかし、ブロックデバイス自体をチェックしても何も変わりません。

# hexdump /dev/mmcblk0p2 -s 200M
c800000 0000 0000 0000 0000 0000 0000 0000 0000
*
c900000 2dee 8ea4 2116 1981 252f d113 afc1 3182
c900010 e6fc 7d1b d173 3cab 4399 8715 bcdf 2272

1MiBのゼロがあり、その後にLVMボリュームに書き込まれたものと一致しないいくつかのゴミがあります。しかし、楽しんでシステムを再起動して再確認してみました。

# hexdump /dev/mmcblk0p2 -s 200M
c800000 0000 0000 0000 0000 0000 0000 0000 0000
*
c900000 2358 898b a13b 8d94 39a1 bff6 8b38 79ec
c900010 9155 1202 ce46 938f 49dc 7687 f804 bf13

データがあります！それでも1MiBのゼロ部分（おそらくヘッダー？）がありますが、記録されたデータ/dev/vg0/volume_bは/dev/mmcblk0p2。

これは本当に説明できません。私の考えでは、LVMとカーネルドライバ間のリンク、より具体的にはカーネルがディスクキャッシュを処理する方法に問題があるかもしれません。 LVを介して現在キャッシュされている領域に物理ディスクを書き込む場合、キャッシュは更新されないか、ダーティとして表示されない可能性がありますか？

組み込みシステムなので電源を切ってから再びオンにしてシステムの再起動をしてみました。動作はまったく同じです。停電が発生する前に、hexdump古いデータが物理デバイスに表示され、再起動後に新しく作成されたデータで更新されます。これは書き込みが完了した後にディスクにフラッシュされ、Linuxの電源切断プロセスの一部ではないことを示します。

根本原因が何なのかまだわからないので、今はこの質問を開いておきます。しかし、少なくとも問題が実際に問題ではないことは知っています。

[編集] 実際にキャッシュが犯人のようです。echo 3 > /proc/sys/vm/drop_caches書き込み後に実行すると、再読み込み時にすぐに更新されます。ウェルフ。

おすすめ記事