Ich habe ein Linux-Software-RAID-10-Setup, das aus 5 RAID 1s (zwei Laufwerke pro gespiegeltem Setup) und einem RAID 0 über alle 5 RAID 1-Paare besteht. Um zu testen, ob keines der Laufwerke unter Last schnell ausfällt, habe ich Badblocks über das RAID 0 mit einem destruktiven Lese-/Schreibmodus verwendet.
Badblocks-Befehl: badblocks -b 4096 -c 98304 -p 0 -w -s /dev/md13
Eines der Geräte ist ausgefallen und anstatt dass das Badblocks-Programm munter weiterlief, blieb es hängen. Wenn ich einen Synchronisierungsbefehl ausführe, bleibt es ebenfalls hängen. Zunächst würde ich annehmen, dass dies kein Standardverhalten für ein RAID 1-Gerät ist. Wenn eines der Laufwerke ausfällt, sollte es trotzdem problemlos auf das virtuelle Gerät schreiben können, das die beiden Laufwerke bilden.
Also habe ich das Laufwerk zwangsweise gelöscht und versucht, es zu entfernen. Ich kann das Laufwerk problemlos auf fehlerhaft setzen (die IO-Vorgänge hängen jedoch immer noch). Ich kann das Gerät nicht vollständig aus dem RAID entfernen, es wird angezeigt, dass es beschäftigt ist. Ich gehe davon aus, dass die IO fortgesetzt wird, wenn ich es vollständig aus dem RAID werfen kann, aber das ist nur eine Annahme und ich glaube, ich habe es mit einer Art Fehler zu tun.
Was ist hier genau los? Bin ich aufgrund eines Fehlers an einem Punkt, an dem ich mich nicht mehr erholen kann?
Auf dem System läuft der Kernel 2.6.18, es ist also nicht gerade neu, aber ich würde denken, dass derartige Probleme nicht auftreten würden, da es Software-Raids schon so lange gibt.
Jede Einsicht wird sehr geschätzt.
mdadm --detail /dev/md13
/dev/md13:
Version : 00.90.03 Creation Time : Thu Jan 21 14:21:57 2010 Raid Level : raid0 Array Size : 2441919360 (2328.80 GiB 2500.53 GB) Raid Devices : 5Anzahl der Geräte insgesamt: 5 Bevorzugte Nebengeräte: 13 Persistenz: Superblock ist persistent
Update Time : Thu Jan 21 14:21:57 2010 State : clean Active Devices : 5 Working Devices : 5Ausgefallene Geräte: 0 Ersatzgeräte: 0
Chunk Size : 64K UUID : cfabfaee:06cf0cb2:22929c7b:7b037984 Events : 0.3 Number Major Minor RaidDevice State 0 9 7 0 active sync /dev/md7 1 9 8 1 active sync /dev/md8 2 9 9 2 active sync /dev/md9 3 9 10 3 active sync /dev/md10 4 9 11 4 active sync /dev/md11
Die fehlgeschlagene Raid-Ausgabe:
/dev/md8: Version: 00.90.03 Erstellungszeit: Donnerstag, 21. Januar 2010, 14:20:47 Raid-Level: raid1 Array-Größe: 488383936 (465,76 GiB 500,11 GB) Gerätegröße: 488383936 (465,76 GiB 500,11 GB) Raid-Geräte: 2
Geräte gesamt: 2 Bevorzugter Minor: 8 Persistenz: Superblock ist persistentUpdate Time : Mon Jan 25 04:52:25 2010 State : active, degraded Active Devices : 1 Working Devices : 1Ausgefallene Geräte: 1 Ersatzgeräte: 0
UUID : 2865aefa:ab6358d8:8f82caf4:1663e806 Events : 0.11 Number Major Minor RaidDevice State 0 65 17 0 active sync /dev/sdr1 1 8 209 1 faulty /dev/sdn1
Antwort1
Entschuldigung, vielleicht habe ich es nicht richtig verstanden und ein cat /proc/mdstat könnte hilfreich sein, aber soweit ich das sehe, haben Sie sich selbst ins Bein geschossen, indem Sie Ihre Daten auf RAID0 und damit auf den zugrunde liegenden RAID1-Arrays zerstört haben. Wenn Sie die RAID-Zuverlässigkeit testen müssen, müssen Sie ein Laufwerk, eine Festplatte, als fehlerhaft markieren, um keine logischen Blöcke zu zerstören, die sich auf alle zugrunde liegenden RAID1-Festplatten beziehen, wenn ich das Problem richtig verstanden habe (lassen Sie es mich wissen).
Antwort2
Möglicherweise müssen Sie den Kernel bitten, das fehlerhafte Laufwerk zu entfernen. Dadurch wird das hängende RAID freigegeben.
Sie können es mit einem Skript wie diesem entfernenhttp://bash.cyberciti.biz/diskadmin/rescan-linux-scsi-bus/