將 LVM 卷歸零的問題

我在一個 eMMC 設備上有一個帶有兩個 LVM 卷的系統，我試圖通過用零填充其中一個卷來“擦除”它。這是我第一次使用 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
• vg0由一個 PV 組成，/dev/mmcblk0p2
• PV 為 3.42GiB，分成 876 個 4MiB PE
• 私募股權$$ 0, 49 $$正在儲存第一個 LV，volume_a
• 私募股權$$ 50, 99 $$正在儲存第二個 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

根據 的輸出pvdisplay -m，我假設 PE

$$ 50, 99 $$(200M-400M)的/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

有一些零，但僅適用於 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 的實際塊寫入。不幸的是，這與我所看到的不一致。

$$ edit1 $$我曾經hexdump檢查過它的內容/dev/vg0/volume_b，不出所料，它充滿了隨機垃圾。它只是讓我意識到hexdump整個/dev/mmcblk0p2並用於grep查找數據的儲存位置。這目前正在進行中，如果可行，我將對其進行更新。 $$ edit2 $$搜尋結果一無所獲

經過更多測試，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 關機過程的一部分。

由於我仍然不確定其根本原因是什麼，因此我將把它打開一段時間，但至少我知道這個問題並不是真正的問題。

$$ edit $$看起來記憶體肯定是罪魁禍首。在寫入之後執行echo 3 > /proc/sys/vm/drop_caches會導致回讀立即更新。韋爾普。

引用自：https://unix.stackexchange.com/questions/327128