Ich habe gerade dasselbe Problem auf zwei brandneuen und identischen Servern entdeckt, die erst vor etwa 9 Monaten installiert wurden. Ich konnte auf beiden nicht auf die Festplatte schreiben, weil das System sie als schreibgeschützt markiert hatte. Die Protokolle zeigten an, dass auf beiden eine Art Festplattenfehler auftrat.
Beachten Sie, dass ich KVM mit mehreren Gästen auf jedem dieser Server betreibe. Die Gäste liefen alle einwandfrei, aber das Problem lag beim KVM-Host. Das spielt wahrscheinlich keine Rolle, aber vielleicht ist es relevant. Beide Systeme haben nurzwei Laufwerkemit Software-Raid1 und LVM obendrauf. Jeder KVM-Gast hat auch seine eigene LVM-Partition.
Bei der Betrachtung wurde auf beiden Systemen ein verschlechtertes RAID1-Array angezeigt /proc/mdstat.
Also habe ich eines der Systeme neu gestartet und es wurde mir angezeigt, dass ich manuell ausführen muss fsck. Also habe ich das getan. Dadurch waren die Probleme anscheinend behoben und nach einem Neustart lief das System wieder normal. Derselbe Vorgang funktionierte auch auf dem zweiten Server.
Als nächstes habe ich versucht mdadm --manage /dev/md0 --add /dev/sdb1, das ausgefallene Laufwerk wieder zum Array hinzuzufügen. Das hat auf beiden Servern gut funktioniert. In der nächsten Stunde oder so /proc/mdstatzeigte ein Blick auf , dass die Laufwerkssynchronisierung Fortschritte machte. Nach etwa einer Stunde war ein System fertig und /proc/mdstatzeigte, dass alles gut funktionierte [UU].
Auf dem anderen System jedoch schoss die Systemlast nach etwa 1,5 Stunden in die Höhe und nichts reagierte. Ein paar Minuten später ging alles wieder. Aber jetzt sieht man /proc/mdstatFolgendes:
root@bond:/etc# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sda1[2] sdb1[1]
293033536 blocks [2/1] [_U]
unused devices: <none>
Wie Sie sehen, wird die Synchronisierung anscheinend nicht mehr durchgeführt. Der Prozentsatz der Fertigstellung, die verbleibende Zeit usw. werden nicht mehr angezeigt. Beim Ausführen wird jedoch mdadm --detail /dev/md0Folgendes angezeigt:
root@bond:/etc# mdadm --detail /dev/md0
/dev/md0:
Version : 00.90
Creation Time : Mon Nov 30 20:04:44 2009
Raid Level : raid1
Array Size : 293033536 (279.46 GiB 300.07 GB)
Used Dev Size : 293033536 (279.46 GiB 300.07 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Fri Sep 10 23:38:33 2010
State : clean, degraded
Active Devices : 1
Working Devices : 2
Failed Devices : 0
Spare Devices : 1
UUID : 4fb7b768:16c7d5b3:2e7b5ffd:55e4b71d
Events : 0.5104310
Number Major Minor RaidDevice State
2 8 1 0 spare rebuilding /dev/sda1
1 8 17 1 active sync /dev/sdb1
Die untere Zeile scheint anzuzeigen, dass das Ersatzgerät neu erstellt wird. Warum ist es ein Ersatzgerät? Das System meldet beide Geräte als sauber. Das ist seit Stunden so geblieben. Die Laufwerke sind kleine und schnelle VelociRaptors mit 300 GB und 10.000 U/min, daher würde ich annehmen, dass die Synchronisierung inzwischen abgeschlossen ist. Beim erneuten Hinzufügen wird angezeigt, dass das Gerät beschäftigt ist:
root@bond:/etc# mdadm /dev/md0 --re-add /dev/sda
mdadm: Cannot open /dev/sda: Device or resource busy
Das Ausführen von dmesg auf dem „guten“ Server zeigt am Ende Folgendes:
[ 4084.439822] md: md0: recovery done.
[ 4084.487756] RAID1 conf printout:
[ 4084.487759] --- wd:2 rd:2
[ 4084.487763] disk 0, wo:0, o:1, dev:sda1
[ 4084.487765] disk 1, wo:0, o:1, dev:sdb1
Auf dem „schlechten“ Server werden diese letzten 4 Zeilen hunderte Male wiederholt. Auf dem „guten“ Server werden sie nur einmal angezeigt.
Werden die Laufwerke noch synchronisiert? Wird dieser „Neuaufbau“ abgeschlossen? Muss ich einfach noch etwas Geduld haben? Wenn nicht, was soll ich jetzt tun?
AKTUALISIEREN:
Ich habe gerade neugestartet und das Laufwerk hat wieder mit der Synchronisierung begonnen. Nach fast 2 Stunden ist das Gleiche passiert wie oben beschrieben (es kommt immer noch ein [_U]). Ich konnte mir jedoch die dmesg-Protokolle ansehen, bevor die RAID1-Konfigurationsausdrucke alles verbrauchten:
[ 6348.303685] sd 1:0:0:0: [sdb] Unhandled sense code
[ 6348.303688] sd 1:0:0:0: [sdb] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 6348.303692] sd 1:0:0:0: [sdb] Sense Key : Medium Error [current] [descriptor]
[ 6348.303697] Descriptor sense data with sense descriptors (in hex):
[ 6348.303699] 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
[ 6348.303707] 22 ee a4 c7
[ 6348.303711] sd 1:0:0:0: [sdb] Add. Sense: Unrecovered read error - auto reallocate failed
[ 6348.303716] end_request: I/O error, dev sdb, sector 586065095
[ 6348.303753] ata2: EH complete
[ 6348.303776] raid1: sdb: unrecoverable I/O read error for block 586065024
[ 6348.305625] md: md0: recovery done.
Daher sollte ich vielleicht eher fragen: „Wie führe ich fsck auf einer Ersatzfestplatte in einem RAID-Set aus?“
Antwort1
Mir ist nicht klar, ob Sie die ausgefallenen Laufwerke tatsächlich ersetzt haben. Denn Ihre Symptome würden für mich Sinn ergeben, wenn Sie das fehlerhafte Laufwerk erneut hinzugefügt hätten. In diesem Fall besteht eine gute Chance, dass das Laufwerk blockiert ist. Wenn Sie das fehlerhafte Laufwerk erneut hinzugefügt haben, gibt es anschließende Fehler in /var/log/messages oder dmesg?
(Übrigens rate ich dringend davon ab, ein fehlerhaftes Laufwerk jemals wieder zu einem RAID-Array hinzuzufügen. Wenn der Fehler Daten auf der Platte beschädigt hat, kann es sein, dass beim erneuten Hinzufügen zum Array die beschädigte Datei durch die Neusynchronisierung auf der Platte verbleibt und es beim nächsten Lesen der Dateien reines Glücksspiel ist, ob Sie gute oder schlechte Daten erhalten, je nachdem, welche Platte zuerst reagiert; ich habe das in der Praxis schon erlebt.)
Antwort2
Mit mdadm --details wird ein Laufwerk während des Wiederaufbaus als Ersatzlaufwerk aufgeführt. Nach Abschluss des Wiederaufbaus wird es nicht mehr als Ersatzlaufwerk angezeigt.
[ 6348.303711] sd 1:0:0:0: [sdb] Add. Sense: Unrecovered read error - auto reallocate failed
[ 6348.303716] end_request: I/O error, dev sdb, sector 586065095
[ 6348.303753] ata2: EH complete
[ 6348.303776] raid1: sdb: unrecoverable I/O read error for block 586065024
[ 6348.305625] md: md0: recovery done.
In der ersten Zeile heißt es, dass es einen Neuzuweisungsfehler gab und die Daten nicht gelesen wurden. Die folgenden drei Zeilen weisen darauf hin, dass die Daten nicht gelesen werden konnten, und listen die Sektoren auf, die nicht lesbar sind.
Wie Rodger betonte, ist das Laufwerk defekt. Fügen Sie es nicht erneut hinzu. Es ist nie eine gute Idee, ein defektes Laufwerk erneut hinzuzufügen. Ziehen Sie das Laufwerk heraus und ersetzen Sie es. Wenn Sie möchten, führen Sie eine Diagnose für das defekte Laufwerk durch, aber erst, nachdem es herausgezogen und ersetzt wurde.
Antwort3
Erstens: Entfernen Sie alle Datenträger, die Lesefehler verursachen, die in der Protokolldatei landen. Dies bedeutet, dass die fehlerhafte Blockverschiebung fehlgeschlagen ist und/oder das Laufwerk kurz vor dem Absturz steht.
Ich empfehle zur Rettung Ihrer Daten eine Linux-Rettungs-CD wiehttp://ubuntu-rescue-remix.org/um ddrescue zu verwenden. Dies kann eine Image-Kopie auf die Partition einer neuen Festplatte erstellen und wird viele Wiederholungsversuche usw. durchführen, um zu versuchen, Ihre Partition wiederherzustellen. Mounten Sie ein USB-Laufwerk oder eine andere Partition
mkdir /tmp/x und mount /dev/sdd1 /tmp/x
um die ddrescue-Protokolldatei zu speichern. Anschließend können Sie ddrescue stoppen (Strg+C) und später an derselben Stelle neu starten.
Erstellen Sie auf der neuen Festplatte eine Partition, die etwas größer ist als die alte. Sie müssen nicht die ganze Festplatte verwenden!
Booten Sie die Rettungs-CD mit "nodmraid" als Kernel-Boot-Parameter. Wenn Sie eine Ubuntu-Live-CD verwenden, installieren Sie RAID und LVM, falls Sie es verwenden.
apt-get installiere mdadm lvm2 gddrescue
Sie müssen mit dem Internet verbunden sein, damit dies funktioniert. Andernfalls verwenden Sie die Ubuntu-Rettungs-CD für den ddrescue-Schritt. Ich habe zwischen der Rettungs-CD für ddrescue-Läufe und der Live-CD für die Arbeit mit Grub und fsck gewechselt.
Angenommen, /dev/sdb ist Ihre fehlerhafte Quellfestplatte, /dev/sdx ist Ihre neue Festplatte und /mnt/x ist ein USB-Stick oder eine Partition auf einer anderen Festplatte, die gemountet wurde. Siebrauchendie ddrescue-Protokolldatei, wirklich! Da sie den Fortschritt von ddrescue verfolgt und eine Unterbrechung zulässt.
Gemäßhttp://www.forensicswiki.org/wiki/Ddrescue
ddrescue --no-split /dev/sdb /dev/sdX Imagedatei /mnt/x/Logdatei
Dann
ddrescue --direct --max-retries=3 /dev/sdb /dev/sdX /mnt/x/logfile
Dann
ddrescue --direct --retrim --max-retries=3 /dev/sdb /dev/sdX /mnt/x/logfile
Scheuen Sie sich nicht, den Vorgang mit Strg+C zu beenden, wenn die Wiederherstellung eines einzelnen Sektors Stunden dauert. Fahren Sie einfach mit dem nächsten Schritt fort (Schritt 1 sollte auf jeden Fall erfolgreich sein). Der letzte Schritt versucht, die letzten Krümel verwertbarer Daten wiederherzustellen.
Sie müssen auch
mdadm --create /dev/md99 --level-1 --raid-devices=2 fehlt /dev/sdX
um ein neues RAID-Array mit der neuen Festplatte zu erstellen, wird ein neuer RAID-Superblock auf die Partition geschrieben (in den letzten 64 KB bis 128 KB am Ende der Partition).
Entfernen Sie Ihre alte, fehlerhafte Festplatte /dev/sdb aus dem System, sodass sie für Linux nicht sichtbar ist.
Machen Sie Ihre Quell-RAID-Festplatte zugänglich. Möglicherweise müssen Sie den Parameter "nodmraid" für den Kernel verwenden, der den Kernel startet, da ich Probleme mit der Ubuntu-Rettungs-CD hatte und schließlich die Ubuntu-Live-CD (10.4) verwendete, auf der sich nodmraid in den F6-Optionen befindet. Sie müssen nur Folgendes verwenden:
mdadm --assemble /dev/md99 /dev/sdX
Führen Sie dann fsck oder eine andere erforderliche Prüfung der Daten auf dem md99-RAID-Array durch (ich habe vgscan verwendet und konnte dann die LVM-LVs sehen, an denen die Prüfung durchgeführt werden sollte). Ich verwende XFS für MythTV, aber der Befehl xfs_check hat mein System zum Absturz gebracht, aber xfs_repair war in Ordnung.
Mounten Sie das /boot-Verzeichnis von Ihrem neuen /dev/sdX
mount /dev/mapper/my_vg/root_lv /tmp/x
Legen Sie dann einen neuen GRUB-Bootdatensatz auf der neuen /dev/sdX-RAID-Festplatte an (nur, wenn Sie von RAID booten!)
grub-setup -d /tmp/x/boot/grub /dev/sdX
jetzt haben Sie ein (fast) bootfähiges RAID-Array. Sie können das Setup auch mit GRUB selbst durchführen oder mit dd die ersten 446 Bytes von /dev/sdb nach /dev/sdX kopieren. NUR die ersten 446 Bytes, der Rest des 1. Sektors ist Ihre Partitionstabelle, die Sie gewaltig verstopfen werden, wenn Sie mehr kopieren! Möglicherweise müssen Sie dasselbe auch für den 1. Sektor in Ihrer Partition /dev/sdX1 (sagen wir) tun. Sichern Sie alle Sektoren, die Sie überschreiben möchten, ebenfalls mit dd.
Wenn Sie grub2 verwenden und von RAID booten, werden Sie feststellen, dass sich die UUID des RAID-Arrays geändert hat, sodass Ihr Bootvorgang fehlschlägt. Bearbeiten Sie die Boot-Befehlszeile (e im Grub-Startfenster), um Splash und Quiet zu entfernen, damit Sie sehen können, was passiert. Nach dem fehlgeschlagenen Bootvorgang befinden Sie sich dann in initramfs.
mdadm --assemble /dev/md99 /dev/sdX
Überprüfen Sie dann /proc/mdstat, um sicherzustellen, dass das Array vorhanden ist. Wenn dies der Fall ist, beenden Sie einfach das Array und hoffentlich funktioniert Ihr GRUB-Boot-Abschnitt einwandfrei (meiner war auf die Verwendung von LVM eingestellt, sodass er die LVs auf dem RAID-Gerät einfach gefunden hat, sobald ein RAID-Gerät vorhanden war, und einfach nach dem LV gesucht hat). Sobald Sie hochgefahren sind, sind Sie fast fertig.
Die initrd-Image-Datei (gzippte cpio-Datei) enthält eine Kopie von mdadm.conf, die während des Bootvorgangs verwendet wird und während des Bootvorgangs als /etc/mdadm/mdamdm.conf sichtbar und editierbar ist. Wenn Sie Ihr System normal booten können, aktualisieren Sie einfach das initramfs mit
update-initramfs -u
Wenn Sie das System aufgrund der nicht übereinstimmenden UUID in der Datei mdadm.conf nicht booten können
Beachten Sie, dass Ihr Zielgerät /dev/sdX möglicherweise als /dev/sdY angezeigt wird, wenn Sie auf eine andere Art booten (Grub, Rescue, Real Boot).
Übrigens, es sei denn, Sie verwenden RAID5 und sind wirklich an Blockausrichtung interessiert, würde ich eine Partition für Ihr RAID-Array verwenden. Sie müssen nicht eine ganze Festplatte verwenden (insbesondere, wenn Sie eine 1-TB-Festplatte durch eine 2-TB-Festplatte ersetzen). Sie können später immer noch eine weitere Partition und ein zweites RAID-Array hinzufügen, um die gesamten 2 TB zu nutzen.
Puh! Fertig!