題 分區恢復後,一個奇怪的問題與ext4 / lvm / raid-5有關


我有3個硬盤,在以下段落中命名為/ dev / sda,/ dev / sdb和/ dev / sdc,最新的是第一個。注意:/ dev / sdc有一個主分區/ dev / sdc1,一個擴展分區/ dev / sd2和3個邏輯分區/ dev / sdc5,/ dev / sdc6和/ dev / sda7。

我用/ dev / sda5和/ dev / sdb5創建了降級的RAID 5設備/ dev / md0(計劃將/ dev / sdc5添加到RAID以將其轉換為正常狀態),然後使用/ dev / md0作為唯一的pv LVM,並使用ext4文件系統/ dev / mapper / vg0-lv0創建了一個lv。

不幸的是,在探索和玩LVM時,我已經跑了 dd if=/dev/zero of=/dev/sdc1 bs=64M count=10 刪除/ dev / sdc1後。所以實際上零被寫入/ dev / sdc2,並且存儲在/ dev / sdc2和/ dev / sdc5的開頭部分的分區表的部分被破壞。

實現這一點後,我立即通過dd製作了/ dev / sdc的圖像,如下所示: dd if=/dev/sdc of=/mount-point-of-vg0-lv0/sdc.img

幾天后,我終於有時間嘗試恢復/ dev / sdc上的數據,實際上只有/ dev / sdc7,因為它是唯一沒有備份的分區。我使用圖像文件sdc.img運行testdisk,使用其快速搜索功能重建分區表,將其丟失到/ dev / loop0。 / dev / loop0p7(這是/ dev / sdc7的映像)返回並可安裝,所有文件似乎都可以。然後我跑了 find /mount-point-of-loop0p7 -type f -exec md5sum {} \; > sdc7_img.md5sum 為/ dev / loop0p7上的所有文件構建MD5校驗和列表。

在處理物理/ dev / sdc設備時,深度搜索的快速搜索找不到所有分區。然後我使用類似命令為物理/ dev / sdc7上的所有文件構建了MD5校驗和列表sdc7.md5sum。將它與sdc7_image.md5sum進行比較時,發現4個文件不同。手動比較後,我注意到每個文件只有1個字節的差異。並且因為一個文件的名稱中有CRC32,所以我可以確認物理/ dev / sdc7中的那個是正確的。

所以我的問題是,為什麼這個奇怪的事情發生了?我已經跑了 fsck.ext4 -c -c /dev/mapper/vg0-lv0 確認它沒有壞塊。 1.2TB數據中的4個字節差異是如此小的百分比,但這使我對將來在/ dev / mapper / vg0-lv0上存儲數據沒有信心。

更新:我不得不提一下,所有的操作都是在VirtualBox 4.1.16中運行的最新ArchLinux中完成的,它運行在Windows 7中./ dev / sda,/ dev / sdb和/ dev / sdc都與物理硬盤鏈接,通過 VBoxManage internalcommands createrawvmdk。在物理磁盤脫機後,VirtualBox僅在物理/ dev / sdc7的md5sums期間報告了錯誤VERR_ACCESS_DENIED diskpart Win7,沒有進一步的錯誤。


5
2018-06-06 17:34


起源




答案:


有幾件事可能發生。首先,您沒有提到在映像磁盤之前卸載sdc7,因此可能是當時正在寫入數據。我猜不會是這種情況,或者你不會問。我不能錯過你對“第一件事,成像磁盤”的反應,這是一個非常好的反應。雖然我注意到在重新啟動之前,內核仍然在內存中有分區表,請檢查 /proc/partitions

首先要檢查的是內存錯誤。你可能有不好的內存。毫無疑問,您的數據會多次通過RAM。我假設你沒有ECC內存,這可能會抓住這個。

硬盤也有錯誤。查看一些隨機消費類硬盤的規格表,他們說每100 Tbit 1個。你複製了1.2TB至少幾次(從源讀取,從目的地讀取),這就像19Tbit讀取。有一點誤差是可信的。 (遺憾的是,它們沒有給出規格表上的寫入錯誤率)。

單字節損壞背後是否有任何押韻或原因? cmp -l 可以告訴你變化的字節。例如,如果頁面中的偏移總是相同(頁面大小可能是4K),並且始終是相同的位,則幾乎可以確定地指向有缺陷的RAM。即使它只是總是相同的位,或相同的偏移量,這是非常確定的(你是否有所有四個文件的CRC32,或只有一個?)


0
2018-06-13 18:36