Ich habe 3 Festplatten, in den folgenden Abschnitten mit den Namen /dev/sda, /dev/sdb und /dev/sdc, die neueste kam zuerst. Hinweis: /dev/sdc hat eine primäre Partition /dev/sdc1, eine erweiterte Partition /dev/sd2 und 3 logische Partitionen /dev/sdc5, /dev/sdc6 und /dev/sda7.
Ich habe ein degradiertes RAID 5-Gerät /dev/md0 mit /dev/sda5 und /dev/sdb5 erstellt (ich hatte vor, /dev/sdc5 zum RAID hinzuzufügen, um es in den Normalzustand zu versetzen), dann /dev/md0 als einziges PV von LVM verwendet und ein LV mit dem Ext4-Dateisystem /dev/mapper/vg0-lv0 erstellt.
Leider bin ich beim Erkunden und Spielen mit LVM nach dem Löschen von /dev/sdc1 ausgefallen dd if=/dev/zero of=/dev/sdc1 bs=64M count=10. Daher wurden die Nullen tatsächlich in /dev/sdc2 geschrieben und ein Teil der Partitionstabelle, die auf /dev/sdc2 gespeichert war, und der Anfangsteil von /dev/sdc5 beschädigt.
Als mir das klar wurde, habe ich sofort per dd ein Image von /dev/sdc erstellt, und zwar wie folgt: dd if=/dev/sdc of=/mount-point-of-vg0-lv0/sdc.img.
Einige Tage später habe ich endlich Zeit, die Daten auf /dev/sdc wiederherzustellen, eigentlich nur auf /dev/sdc7, da dies die einzige Partition ohne Backup ist. Ich habe testdisk mit der Image-Datei sdc.img ausgeführt, die Schnellsuchfunktion verwendet, um die Partitionstabelle neu zu erstellen, und sie auf /dev/loop0 verschoben. /dev/loop0p7 (das Image von /dev/sdc7) war wieder da und konnte gemountet werden, und alle Dateien scheinen in Ordnung zu sein. Dann habe ich versucht, find /mount-point-of-loop0p7 -type f -exec md5sum {} \; > sdc7_img.md5sumeine MD5-Prüfsummenliste für alle Dateien auf /dev/loop0p7 zu erstellen.
Beim Umgang mit dem physischen /dev/sdc-Gerät findet die Schnellsuche von testdisk nicht alle Partitionen, die Tiefensuche schon. Dann habe ich mit einem ähnlichen Befehl die MD5-Prüfsummenliste sdc7.md5sum für alle Dateien auf dem physischen /dev/sdc7 erstellt. Beim Vergleich mit sdc7_image.md5sum habe ich festgestellt, dass 4 Dateien unterschiedlich sind. Nach dem manuellen Vergleich habe ich festgestellt, dass sich jede Datei nur um 1 Byte unterscheidet. Und da eine Datei CRC32 im Namen hat, kann ich bestätigen, dass die Datei vom physischen /dev/sdc7 korrekt ist.
Meine Frage ist also, warum dieses seltsame Ding passiert ist. Ich habe bereits alles überprüft, fsck.ext4 -c -c /dev/mapper/vg0-lv0um zu bestätigen, dass es keine fehlerhaften Blöcke gibt. 4 Byte Unterschied bei 1,2 TB Daten sind ein so kleiner Prozentsatz, aber das lässt mich in Zukunft kein Vertrauen mehr darin haben, Daten auf /dev/mapper/vg0-lv0 zu speichern.
Update: Ich muss erwähnen, dass alle Vorgänge im neuesten ArchLinux unter VirtualBox 4.1.16 durchgeführt wurden, das unter Windows 7 läuft. /dev/sda, /dev/sdb und /dev/sdc sind alle über mit physischen Festplatten verknüpft VBoxManage internalcommands createrawvmdk. VirtualBox hat nur den Fehler VERR_ACCESS_DENIED gemeldet, während MD5-Summen für das physische /dev/sdc7 erstellt wurden. Nachdem die physische Festplatte über Win7 offline geschaltet wurde diskpart, traten keine weiteren Fehler auf.
Antwort1
Es gibt ein paar Dinge, die passiert sein könnten. Erstens haben Sie nicht erwähnt, dass Sie sdc7 ausgehängt haben, bevor Sie das Image der Festplatte erstellt haben. Es könnte also sein, dass die Daten zu diesem Zeitpunkt geschrieben wurden. Ich gehe jedoch davon aus, dass dies nicht der Fall war, sonst würden Sie nicht fragen. Ich kann Ihre Reaktion „als Erstes das Image der Festplatte erstellen“ nicht bemängeln, das ist eine ziemlich gute Reaktion. Ich stelle jedoch fest, dass der Kernel vor dem Neustart noch die Partitionstabelle im Speicher hatte, überprüfen Sie /proc/partitions.
Als erstes sollten Sie nach Speicherfehlern suchen. Möglicherweise ist Ihr RAM defekt. Ihre Daten sind zweifellos mehrmals durch den RAM gegangen. Ich gehe davon aus, dass Sie keinen ECC-Speicher haben, der dies wahrscheinlich erkennen würde.
Festplatten haben auch Fehler. Wenn man sich die Datenblätter einiger Festplatten für Verbraucher ansieht, steht dort 1 pro 100 Tbit. Sie haben 1,2 TB mindestens ein paar Mal kopiert (von der Quelle lesen, vom Ziel lesen), das sind also etwa 19 Tbit Lesevorgänge. Dass da ein Bitfehler drin ist, ist glaubhaft. (Leider wird in den Datenblättern keine Fehlerrate für Schreibvorgänge angegeben.)
Gab es irgendeinen Sinn oder Zweck hinter den Einzelbyte-Beschädigungen? cmp -lIch kann Ihnen die Bytes nennen, die variieren. Wenn es beispielsweise immer der gleiche Offset auf einer Seite wäre (Ihre Seitengröße beträgt wahrscheinlich 4 KB) und immer das gleiche Bit, würde das fast eindeutig auf defekten RAM hinweisen. Selbst wenn es nur immer das gleiche Bit oder der gleiche Offset wäre, wäre das ziemlich eindeutig (Und hatten Sie CRC32 für alle vier Dateien oder nur für eine?)