Die Kurzfassung: Wie würde ich vorgehen, um einen fehlerhaften Block auf einer Festplatte in einem RAID1-Array zu reparieren?
Aber bitte lesen Sie das Ganze, um zu erfahren, was ich bereits versucht habe und welche Fehler in meinen Methoden möglich sind. Ich habe versucht, so detailliert wie möglich zu sein, und hoffe wirklich auf Feedback
Das ist meine Situation: Ich habe zwei 2TB-Festplatten (dasselbe Modell) in einem RAID1-Array eingerichtet, das von verwaltet wird mdadm. Vor etwa 6 Monaten bemerkte ich den ersten fehlerhaften Block, als SMART ihn meldete. Heute sind mir weitere aufgefallen und ich versuche nun, das Problem zu beheben.
Diese HOWTO-Seitescheint der einzige Artikel zu sein, auf den alle verlinken, um fehlerhafte Blöcke zu beheben, die SMART meldet. Es ist eine großartige Seite voller Informationen, aber sie ist ziemlich veraltet und geht nicht auf mein spezielles Setup ein. So unterscheidet sich meine Konfiguration:
- Anstelle einer Festplatte verwende ich zwei Festplatten in einem RAID1-Array. Eine Festplatte meldet Fehler, während die andere einwandfrei funktioniert. Das HOWTO ist nur für eine Festplatte geschrieben, was verschiedene Fragen aufwirft, wie z. B. „Verwende ich diesen Befehl auf dem Festplattengerät oder dem RAID-Gerät?“
- Ich verwende GPT, das von fdisk nicht unterstützt wird. Stattdessen verwende ich gdisk und hoffe, dass es mir die gleichen Informationen liefert, die ich brauche.
Also, lasst uns zur Sache kommen. Das habe ich getan, aber es scheint nicht zu funktionieren. Bitte überprüfen Sie meine Berechnungen und meine Methode noch einmal auf Fehler. Die Festplatte, die Fehler meldet, ist /dev/sda:
# smartctl -l selftest /dev/sda
smartctl 5.42 2011-10-20 r3458 [x86_64-linux-3.4.4-2-ARCH] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net
=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed: read failure 90% 12169 3212761936
Daraus können wir schließen, dass der Fehler bei LBA 3212761936 liegt. Gemäß dem HOWTO verwende ich gdisk, um den Startsektor zu finden, der später zur Ermittlung der Blocknummer verwendet wird (da ich fdisk nicht verwenden kann, da es GPT nicht unterstützt):
# gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.5
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 3907029168 sectors, 1.8 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): CFB87C67-1993-4517-8301-76E16BBEA901
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 3907029134
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)
Number Start (sector) End (sector) Size Code Name
1 2048 3907029134 1.8 TiB FD00 Linux RAID
Mithilfe von tunefsermittle ich, dass die Blockgröße 4096. Anhand dieser Informationen und der Berechnung aus dem HOWTO komme ich zu dem Schluss, dass der betreffende Block . ist ((3212761936 - 2048) * 512) / 4096 = 401594986.
Anschließend werde ich im HOWTO angewiesen, debugfszu prüfen, ob der Block verwendet wird (ich verwende das RAID-Gerät, da es ein EXT-Dateisystem benötigt. Dies war einer der Befehle, die mich verwirrt haben, da ich zunächst nicht wusste, ob ich /dev/sda oder /dev/md0 verwenden sollte):
# debugfs
debugfs 1.42.4 (12-June-2012)
debugfs: open /dev/md0
debugfs: testb 401594986
Block 401594986 not in use
Block 401594986 ist also leerer Speicherplatz, ich sollte ihn problemlos überschreiben können. Bevor ich ihn beschreibe, versuche ich jedoch sicherzustellen, dass er tatsächlich nicht gelesen werden kann:
# dd if=/dev/sda1 of=/dev/null bs=4096 count=1 seek=401594986
1+0 records in
1+0 records out
4096 bytes (4.1 kB) copied, 0.000198887 s, 20.6 MB/s
Wenn der Block nicht gelesen werden könnte, würde ich nicht erwarten, dass dies funktioniert. Es funktioniert jedoch. Ich wiederhole die Verwendung von /dev/sda, /dev/sda1, /dev/sdb, /dev/sdb1, /dev/md0, und +-5 zur Blocknummer, um um den fehlerhaften Block herum zu suchen. Es funktioniert alles. Ich zucke mit den Schultern und mache weiter und übergebe den Schreib- und Synchronisierungsvorgang (ich verwende /dev/md0, weil ich dachte, dass das Ändern einer Festplatte und nicht der anderen Probleme verursachen könnte. Auf diese Weise überschreiben beide Festplatten den fehlerhaften Block):
# dd if=/dev/zero of=/dev/md0 bs=4096 count=1 seek=401594986
1+0 records in
1+0 records out
4096 bytes (4.1 kB) copied, 0.000142366 s, 28.8 MB/s
# sync
Ich würde erwarten, dass beim Schreiben in den fehlerhaften Block die Festplatten den Block einem fehlerfreien neu zuweisen würden. Das Ausführen eines weiteren SMART-Tests zeigt jedoch etwas anderes:
# 1 Short offline Completed: read failure 90% 12170 3212761936
Zurück zum Ausgangspunkt. Wie würde ich also grundsätzlich einen fehlerhaften Block auf einer Festplatte in einem RAID1-Array reparieren? Ich bin sicher, dass ich etwas nicht richtig gemacht habe ...
Vielen Dank für Ihre Zeit und Geduld.