Raid5 am ICH10 - "failed"

Intel hält es nicht für Notwendig, die Welt darüber zu informieren. Wem der RAID verreckt, hat eben Pech gehabt - scheint die Devise. Einer deren Techniker hat im Linux rumgebastelt, die Infos (oder wie er sich das vorgestellt hat) sind aber nicht ganz richtig gewesen
Datenrettungsfirmen geben diese Infos auch nicht raus, soferne die das wissen, denn die arbeiten meist mit gekaufter Software.

Ich knie schon in Deinem Problem.
Da nicht ganz klar ist, welche Platte zuerst ausgefallen ist (weil die Metadaten durch die nachträgliche Rumstöpslerei überschrieben wurden), suche ich nach einer Möglichkeit, das zu verifizieren.
 
Hmm - ich habe heute mal versucht die Stöpselei etwas zu Rekonstruieren um herauszufinden welche Platte da zuerst abgeschmiert ist. Leider ohne Erfolg. :-/
 
Naja... Sehen wir uns das am WoE mit HxD mal genauer an, ab morgen Abend hab ich Zeit.
 
Schade, habe gehofft dass wir dieses Wochenende ein par Fortschritte machen. :(
 
Sind wir doch, denn ich bin am WoE darangewesen, das Problem nachzustellen, um eine einfache Verifizierungsmöglichkeit zu finden.
Ich bin noch am auswerten, bis das Christkind kommt, haste ihn schon wieder ...
 
OK, mit mehreren Versuchen habe ich eindeutig geklärt, wie die Lage bei Dir aussieht.

HxD Aufruf unter User mit Administratorrechten (oder per rechtklick - Ausführen als ...)
- Menü: Extras/open disk/physical disk/hard disk 1 (Häkchen bei "open as readonly" nicht entfernen)
========= sichern MBR
- Menü: Edit/select block/start: 0 ; length: 200, hex, OK
- Strg+C (Kopiert es in die Zwischenablage)
- Menü: File/New (es erscheint ein Reiter "untitled1")
- Strg+V (überträgt es aus der Zwischenablage - bei popup "File Size change": OK)
- Menü: File/Save as... einen Ordner wählen und Dateiname "MBR.bin"
- Menü: File/Close (es erscheint wieder die markierte Anzeige der hard disk)
- HxD beenden.

Den MBR.bin stellst Du mir gezippt in den Anhang und wartest, bis ich OK gebe, dann kannst Du weitermachen:

- Umstellen des ICH10R im BIOS auf RAID
- Bootreihenfolge auf die Platte mit dem Notsystem richtigstellen, falls verändert.

- nach dem POST mit STrg+I in den Intel BootROM
- Reset aller drei Memberplatten auf non-RAID
- die Reihenfolge der Platten muss so angezeigt werden:
S20BJ90Z813306
S20BJ90Z813314
S20BJ90Z813347

Dann mit diesen 3 Platten den RAID-Array wieder definieren

Name: Raid
Typ: parity (RAID5)
Stripesize: 64KB
Size: Max

- exit aus dem Intel-Boot-ROM
lass den POST nochmals durchlaufen, wieder ins BIOS (Keinesfalls aber bis zum Boot ! notfalls mit Power-Off verhindern)
- Boot wieder von der Notsystem-Platte einstellen
- nach Save/Exit im POST Power OFF machen
die zweite Platte S20BJ90Z813314 abklemmen(SATA-Datenkabel).

Power-On, Strg+I nach POST; der RAID muss Status DEGRADED haben und S20BJ90Z813314 fehlen

Vom Notsystem booten

- Menü: Extras/open disk/physical disk/hard disk (um 1 mehr als in der Datenträgerverwaltung für den Raid angezeigt)
(Häkchen bei "open as readonly" diesmal entfernen)

Der Sektor 0 muss komplett leer sein ( nur 00 00 00...) sonst abbrechen, dann bist Du auf der falschen Platte

========= restore MBR
- Menü: File/recent Files --> den früher erstellten MBR.bin wählen
- Strg+A (markiert alles)
- Strg+C (Kopiert es in die Zwischenablage)
- Menü: File/Close (es erscheint wieder die markierte Anzeige der hard disk)

- Menü: Edit/select block/start: 0 ; length: 200, hex, OK
- Strg+V (überträgt es aus der Zwischenablage - bei popup "File Size change": ABBRECHEN, ohne zu speichern!
- Menü: File/Save (schreibt es auf die Platte zurück)
- HxD beenden


In der Eingabeaufforderung vom Laufwerk, welches in der Datenträgerverwaltung für die Partition am RAID5 angezeigt wird, ein chkdsk OHNE PARAMETER durchführen.
Es dürfen keine Fehler gemeldet werden, andernfalls nicht weitermachen!

Power-Off, die fehlende Platte wieder anklemmen
Mit Strg+I in den RAID BootROM
der Status muss jetzt auf Rebuild stehen
- Vom Notsystem booten und das Ende des Rebuild abwarten, und der RAID5 auf Status NORMAL geht.

Dann kannst Du wieder vom System am RAID booten
 
Ok ich werte die Sache morgen mittag angehen und spätestens um 15 Uhr die Datei posten.
Ergänzung ()

So hier die MBR.bin - falls möglich wäre ein "Go" oder "No Go" innerhalb der nächsten Stunde schön, da ich in einigen Stunden verreise. :)
 

Anhänge

Zuletzt bearbeitet:
Die Reihenfolge im Intel Raid bios stimmt nicht...

Port 0 S20BJ90Z813306
Port 2 S20BJ90Z813314
Port 1 S20BJ90Z813347

Was soll ich tun? Die Sata-Ports wechseln?
 
Ja, das ist ja der Zweck der Angabe der Reihenfolge
an den beiden an Port1/2 die Sata-Kabel an den Platten vertauschen
 
Ernst@at schrieb:
In der Eingabeaufforderung vom Laufwerk, welches in der Datenträgerverwaltung für die Partition am RAID5 angezeigt wird, ein chkdsk OHNE PARAMETER durchführen.
Es dürfen keine Fehler gemeldet werden, andernfalls nicht weitermachen!

Ich bin jetzt bei diesem Schritt angelangt, versteh aber nicht ganz was du meinst - der Datenträger ist bei mir nicht partitioniert und hat auch keinen Laufwerksbuchstaben - wie führe ich da jetzt ein chkdisk in der eingaberaufforderung durch?
 
Wenn Du den MBR.bin den ich mir zur Kontrolle angesehen habe, auf die richtige Platte zurückgeschrieben hast, sollte nach einem Neustart und Boot wieder vom Notsystem (das hab ich vergessen, reinzuschreiben) die Partitionierung wieder angezeigt werden...
 
ah ok - ich habe keinen neustart gemacht. gut dann mach ich das jetzt mal
 
ERNST DU BIST EIN GOTT!!!


Soeben ist das Rebuild fertig geworden! :volllol: Damit das zukünftig nicht mehr passiert - hast du einen Rat? Ist das ICH10R überhaupt zu irgendwas brauchbar? Vllt wenigstens ein Raid 0 ? Wie sieht es mit dem Write-Back-Cache? Aktivieren oder Deaktivieren?

Und vor allem: Wie kann man dir danken?! :schluck:
 
Jeder Onboardcontroller hat nur begrenzte Möglichkeiten, in Fehlerfällen richtig zu diagnostizieren, wie das zu recovern wäre. Gerade bei Verwendung von Platten, welche nicht für einen RAID-Betrieb vorgesehen sind, kann die bei Plattenfehlern durch interne Recovery entstehende Verzögerung das Zeitfenster der Geduld auf eine Antwort überschreiten. was ein häufiges Rebuild aus nichtigen Gründen zur Folge haben kann.

Tritt dann zusätzlich in diesem verwundbaren Stadium ein weiteres Problem auf, kann das nicht mehr bewältigt werden, und der Array wird als inoperabel eingestuft, bevor irgendein nicht wiedergutzumachender Unsinn passiert.
Ich sehe dieses Verhalten vergleichbar mit der Funktion eines Fehlerstromschutzschalters in einem elektrischen Verbraucherstromkreis.

Ob der Write-Back-Cache ein- oder ausgeschaltet ist, hat nur Auswirkung auf die Performance, besonders bemerkbar beim Rebuild. Ansonsten ist bei einem Stromausfall selbst mit PSU nicht nachvollziehbar, was noch und was nicht mehr auf den Platten passiert ist, solange die Software/das Filesystem zu keinem Transaktionsrollback fähig ist.
 
Habe ich das also richtig verstanden? Die Onboard-Controller sollte man, wenn überhaupt, lieber nur mit speziellen RAID-Editionen von Festplatten verwenden?
 
Bei RAID5 empfielt es sich, Platten zu verwenden, bei denen eine Zeitbeschränkung in der Recovery eingestellt ist oder eingestellt werden kann.
==> http://en.wikipedia.org/wiki/Time-Limited_Error_Recovery
Bei einigen WD "Consumer Edition" HDDs (im Gegensatz zu den REs) war das Verhalten der HDD-Firmware per Tool einstellbar, bis man diese Funktionalität wohl aus preispolitischen Gründen nicht weiter angeboten hat.

Andernfalls kann jeder Anwender in diese Falle laufen.
Hier bei CB und anderswo zu onboard-Controllern berichtete "Ich habe seit Jahren nie Probleme damit gehabt" resultieren einfach daraus, dass bei jenen glücklicherweise auf den Platten noch nie schlecht lesbare Sektoren aufgetreten sind, die von der Firmware nicht innerhalb weniger Sekunden doch noch erfolgreich gelesen werden konnten..
 
Zuletzt bearbeitet:
Zurück
Oben