Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Western Digital hat offenbar schon vor längerer Zeit die Seriennummern auf 15 Stellen aufgeplustert. Hab hier auf der Arbeit eine WDC WD800JD-60LSA0 im Rechner drin mit der Seriennummer WD-WMAM9X348717 Wie alt ist diese Serie, 5 Jahre?
So, meine ganze Backup-Hardware ist heut Vormittag angekommen.
Wollt die 2TB-Platten eigentlich schnellformatieren, hab aber gelesen, daß die Normalformatierung wohl die bessere Alternative ist (wg. Defekterkennung, Testrun, etc.).
Aber das dauuuuuuuuert! Um ~12Uhr gestartet, jetzt bei 70% = pro Platte ~7Std.
Außerdem muß ich noch auf eine Antwort von LaCie warten, ob man auf der Karte einen Jumper (siehe Anhang) setzen muß, um 3gb/s zu erhalten. So schaut's zumindest aus (Sata-Logo/3gb/s mit einem kleinen Pfeil auf die 2 Pins). Es liegt aber kein Jumper bei & es gibt auch keine Info im Handbuch oder online darüber.
Die 2. Platte wird dann eben über Nacht formatiert.
Spielt es eigentlich einen Unterschied, ob man einen MBR- oder GPT- Datenträger erstellt? Hab jetzt mal GPT gewählt, hoffe die wird später in dem externen Gehäuse auch erkannt. (P.S.: ich nutze kein XP & hab auch nicht vor von diesen Platten zu booten)
Achja -> bis jetzt noch keine Antwort von Western Digital
Du hättest die Platten auch mit einer MBR-Partitionierung versehen können - falls du die Platten mal an einen älteren PC klemmen willst oder so.
Ansonsten ist es eigentlich nicht so wild.
Das Gehäuse hat mit der Partitionierung zu tun - das muss ja nur dafür sorgen, dass die Daten von und zur Platte kommen. Das hat sich daran also nicht zu stören.
Bei der Karte dürften die 2 Pins eher für eine Aktivitäts-LED sein, da die LED vorn am Gehäuse ja nur vom Controller im Chipsatz angesteuert wird.
Nun, wie sieht es aus, sind die neuen Platten schon eingelaufen, alle defekten Sektoren ausgelagert, um die Daten runterzuschaufeln?
Inzwischen können zwei von Deinen Leidensgenossen, Bitman und Russe_89 , die das Schicksal am selben Wochenende getroffen hat, schon wieder 100% ihrer Daten liebevoll in Ihre Arme schließen.
Ja mein Setup steht soweit, Karten verbaut & die beiden Platten haben mittlerweile auch schon einige Stunden
& Gigabite ohne Fehler gemeistert (siehe Anhang). Benchmarks wurden über eSata mit den in den Gehäusen verbauten Platten erstellt. Super Performance, leider keine SMART-Werte mehr auslesbar.
Ich bin grad nur noch dabei meine Systemplatte & meine andern beiden externen Platten auszumisten.
Danach wird mit Acronis TrueImage von allem noch ein neues Backup auf einer der neuen 2TB-Platten erstellt.
War mal ech wieder nötig, kannte mich schon gar nicht mehr aus, wo was liegt.
Sollte bis morgen dann alles rausgeputzt sein. Dann können wir "angreifen".
P.S.:immer noch keine Antwort von Western Digital!.
Die werden wohl nach einer Nachstellung des Falls vom Hocker gefallen sein.
Der LaCie-Support scheint nicht gerade sehr kompetent zu sein.
Mal schaun was ich auf meine 2. Anfrage bekomme, die ein bisschen konkreter & mit mehr Materie formuliert wurde.
Die Karte erscheint im Gerätemanager als "SiliconImage" und nicht als "LaCie", außerdem sind die Treiber, die man auf beiden Seiten herunterladen kann, identisch (sogar gleiche Versions-Nummer).
Die alte Bios-Version die momentan drauf ist, ist auch auf der SiliconImage-Homepage auch zu finden. Sollte dann doch eigentlich passen, das Bios, oder?
Würde das gern noch vor der Aktion als "abgehakt" verbuchen.
Ich kenn mich mit dem DeLock PCIE mit 2 internen Anschlüssen aus - da ist dasselbe drauf, und habe damit auch die Firmware(Controller-BIOS) non-RAID und RAID getestet.
Spezielle Fragen dazu?
Die Labelmodifikation ist wahrscheinlich in den Treiberdateien implementiert, damit dann im Gerätemanager 'LaCie Controller' drinsteht
Andere machen das mittels modifizierter DevID/VendorID der p&p device- und die steht in der Firmware
Die Karte hat ja nicht einmal ein "LaCie"-Label, es steht überall nur "SiliconImage". (siehe Anhang)
Daher bin ich mir auch zu 99% sicher, daß das Bios das richtige ist.
Lt. SiliconImage-Homepage wird der verbaute Chip (SST 39VF010) auch von dem Bios "supported".
Bin nur eben 1% verunsichert nach der LaCie Support-Antwort, daß "dieses Bios nicht von LaCie freigegeben wurde". Eben so eine typische Support-Standard-Antwort, wenn man keinen Plan hat was Sache ist. Warte aber noch auf die 2. Antwort von denen.
Denke, das nun nicht mehr funktionierende "HotSwap" wird mit dem neuen Bios gefixt. Klappte nur die ersten paar mal, jetzt tauchen die Platten nicht mehr "Hardware sicher entfernen"-Liste auf.
Die anderen 3 zerfallenen RAID5 vom letzten Wochenende sind inzwischen wiederhergestellt und in die Freiheit entlassen.
Das mit den 15-stelligen Seriennummern ist bei den WD schon lange so - hat meine Recherche ergeben, ich hatte bisher keinen einzigen zerfallenen RAID5 mit WD-Platten behandelt.
Einer der Neuzugänge hatte die jetzt aber auch, und da hab ich versucht, Dein Problem mit angeordneten Tests nachzuvollziehen - Das Rebuild hat sich selbst durch Unterbrechungen aber überhaupt nicht beeinflussen lassen und brav an seinem Checkpoint aufgesetzt und weitergemacht.
Das wäre ein Indiz dafür, dass bei Dir war anderes der Auslöser war.
Defektes Netzteil oder fehlerhafte Zuleitung, welche beim An/Abstecken der Externen zusammen mit Wiederhochfahren der ersten ausgefallenen zu einem Spannungeinbruch an den anderen und damit verbundene Notabschaltung dieser geführt hat? Auch Netzschwankungen just zu diesem Zeitpunkt könnten mitgespielt haben. Murphy's Gesetz eben.
Die Intel-Controller sind da verwundbar, und ein Programmfehler in so einer Chaoskonstellation hat dazu noch die Metadatenbereiche durcheinandergebracht
(Gedächnisstütze für mich für weitere Vorgangsweise: Rekonstruktionstyp 2; XOR 1+3 wegen 2048 nicht nötig; Erhebung RAIDGPT+Mirror noch ausständig!)
Dann sollten die langen WD Seriennummern nun kein Problem darstellen? Keine manuelle Änderung der Seriennummern nötig, um den Raid zukünftig "sicher" zu betreiben?
Wie ich ja schon in meinem ersten Post schrieb, begann der ganze Mist ja erst, als ich meine externe Platte im laufenden Betrieb an den externen FireWire-Port hängte. Dieser wird, soviel ich weiß, über den JMicron gesteuert, was lt. meinem Bauchgefühl das Problem war.
Der JMicron bietet die Möglichkeit über den internen Sata-Port (an dem mein Brenner hängt) & über den externen eSata-Port (über dem sich der FireWire-Port befindet, an dem ich die Platte ansteckte) einen Raid 0 oder 1 zu erstellen - siehe Handbuch: P5W-DH Deluxe Hardware User's Manual for German Edtion(G2557) (k.a. ob dies auch über den FireWire-Port möglich ist). Kann es sein, daß dieser beim anstecken der Platte versuchte ein Raid zu ertellen & dadurch den ICH7R-Raid beeinflusste? Ist es möglich, daß der JMicron automatisch auf Raid umstellt?
Ich hab nun sicherheitshalber noch die JMicron Raid-Treiber deinstalliert, der JMB36X erscheint nun nicht mehr unter Speichercontroller, sondern unter IDE ATA/ATAPI-Controller. Die Treiber sind doch sowieso nur nötig, falls man ein Raid über den JMicron erstellen will. Für den Einzelbetrieb sind diese doch nicht nötig, oder?
Die zwei Onboard eSata/FireWire-Ports hab ich jetzt mit einem schicken Asus 3D-Sticker "versiegelt", die werden einfach nicht mehr benutzt. Hab jetzt ja mit meiner Kartenerweiterung genügend andere Reserven (+ 2x eSata, 2x FireWire, 4x USB).
Nun, im Experiment im anderen Thread stellten die 15-stelligen Seriennummern kein Problem dar, der RAID ließ sich rebuilden.
Daher sollte das auch bei Dir funktionieren, obwohl es auf den ersten Blick nicht so aussah.
Der jMicron-Controller hat absolut nichts mit dem Intel zu tun, Die SATA/RAID Treiber sind für AHCI notwendig, wenn man z.B. den hinteren eSATA Anschluss nutzt oder intern einen Wechselrahmen damit beschaltet, damit Hotplug funktioniert.
Bei Verwendung beider Anschlüsse ist es empfehlenswert, AHCI einzustellen, damit die beiden Geräte daran sich nicht gegenseitig behindern.
Nachtrag:
Der Firewire-Anschluss hängt ebenfalls an einem eigenen Controller und dürfte eigentlich keinerlei Beeinflussung der anderen beiden hervorrufen.
Was natürlich sein könnte - dass entweder beim Einstecken am hinteren IEEE1394 Port ein Kurzschluss der +12V erfolgte, oder vom externen Netzteil da ein Störpuls drüberkam, der den Platten eine Notabschaltung und Wiederanlauf bescherte.
Jedenfalls wäre von meiner Seite alles für die Wiedererweckung des RAID bereit - Sag, wann es losgehen soll...
Kam nur gerade in die Situation, wo ein Recovery von C: nötig war. Dummerweise konnte ich auf mein Backup auf einer der neuen WD's wegen der GPT-Formatierung mit AcronisTIH nicht zugreifen. Aber das Recovery von einem NAS oder Server unterstützen 'se.
Hat sich dann auch dementsprechend umständlich & zeitaufwendig gestaltet. "Abgesicherter Modus, Backup von der intern angesteckten WD auf E: kopieren, TIH booten & Recovery von C:" war dann die Lösung.
Die beiden WD's werden jetzt in MBR umgewandelt & zusätzlich speichere ich das Backup noch auf E:
Werde das Problem mit dem Lacie-Controller wohl erst nach unserer Aktion testen, ist mir jetzt doch zu risikoreich. Scheint als würden mit dem Hotfix einige Treiber ersetzt - nicht daß das noch bei dem Raid5 dreinfunkt.
Und die Bios-Fragen werden von denen wohl grundsätzlich nicht beantwortet. Scheint als ob da nur fachlich wenig versierte Support-Tanten vor den PC's sitzen.
"Vielen Dank für die zusätzlichen Informationen. Probieren Sie bitte das Hotfix von Microsoft herunterzuladen, damit wir das Problem der HotSwap-Funktion lösen können ; klicken Sie bitte hier:http://support.microsoft.com/kb/950186/de"
Da ich danach eh auf Win7 x64 umsteige, wird sich das Problem vielleicht von selbst erledigen.
Also, wir können dann loslegen.
Ergänzung ()
Update: hab nun endlich die Antwort von Western Digital erhalten (siehe Anahng).
Sehr interessant, es währe in diesem Fall erlaubt die Seriennummern zu ändern. Es wurde auch nicht abgestritten. Hmm, also währe es wohl doch möglich, daß es etwas mit den Seriennummern auf sich hat.
Bezeichnend scheint, dass keine(r) eigentlich eine Ahnung hat, wovon er/sie spricht.
Die Seriennummer selbst ändern... Ja, womit denn bloß? Liefert WD ein Tool dazu?
Oder verwechseln die das mit der Datenträgerkennung im MBR?
Selbst die erste Generation SATA-Platten hatten schon diesen 15-stelligen Code, wogegen wollen die dann eine 1TB tauschen? Gegen 125 Stück 8GB IDE-Drives?
Die Anleitung zur Wiedererweckung werde ich erst am Abend hier reinstellen können, da ich atm etwas beschäftigt bin...
Selbst die erste Generation SATA-Platten hatten schon diesen 15-stelligen Code, wogegen wollen die dann eine 1TB tauschen? Gegen 125 Stück 8GB IDE-Drives?
Sollte man sich wohl mal mit dem "3. Level" in Verbindung setzen.
Entweder haben die A) selbst keinen Plan B) das nur geschrieben, um sich dann über die Aktionen/Reaktion hier im Thread einen Ast abzulachen oder C) da ist wirklich etwas dran.
Kenn mich da jetzt nicht wirklich aus, aber ich gehe jetzt mal davon aus, daß sich die Seriennummer nur ändern lässt mittels Aufspielung eines modifizierten Bios, indem die Seriennummer abgeändert wurde. Ist mir aber nicht bekannt, daß WD jemals Biose zum download bereitgestellt hätte (da geht's ja nicht so zu wie bei Seagate).
Sobald die Daten sicher sind, können wir ja noch testen, wie sich das Raid verhält & ob es tatsächlich mit den Seriennummern Probleme macht.
P.S.: bei WD stehen die Seriennummern auch auf dem Label, allerdings ohne dem "WD-"-Präfix.
Den Test mit WD-Platten im RAID5 an einem Intel-Controller hab ich schon bei einer anderen Fehlerbehebung eingestreut - dabei ist nichts rausgekommen, das Rebuild war trotz mehrerer Abbrüche nicht und nicht umzubringen.
Die komische Situation muss entstanden sein, als zuerst die Memberplatte2 ein Not-Aus wegen zu geringer Spannung mit anschließendem power-up hingelegt hat, und dann im Ansatz zum Rebuild, als die wieder da war, sich die Memberplatten 1 und 3 mit gleichem Symptom verabschiedet haben. Anders lässt sich der Zustand der Metadaten nicht erklären, der Anfangs etwas verwirrend ausgesehen hat...
Auszüge daraus:
Code:
Auf HDD[0] und [2] steht:
HDD [0] - Status Flags: Disk is: Member, Usable, Detected, Claimed,
HDD [1] - Status Flags: Disk is: Member, *** Failed ***, *** Unusable ***, *** Undetected ***,
HDD [2] - Status Flags: Disk is: Member, Usable, Detected, Claimed,
wobei er dann noch auf HDD[2] einen Fehler erkannt hat, der den Status ins FAILED gerissen hat
Auf HDD[1] (die zuerst ausfiel) steht nicht der sonst übliche Inhalt vor dem Ausfall (NORMAL mit
allen drei Platten OK), sondern da wurde, als die wieder online ging, festgestellt:
HDD [0] - Status Flags: Disk is: Member, *** Failed ***, *** Unusable ***, *** Undetected ***,
HDD [1] - Status Flags: Disk is: Member, Usable, Detected, Claimed,
HDD [2] - Status Flags: Disk is: Member, *** Failed ***, *** Unusable ***, *** Undetected ***,
d.h. zu diesem Zeitpunkt waren die anderen beiden Platten nicht online.
Ergänzung ()
Bevor wir jetzt dem Array wieder Leben einhauchen, brauche ich noch zur Sicherheit Daten von den ersten beiden Memberplatten:
Steck erst mal Member2 (WCASJ1336241) an den Port 0 des jMicron, damit das in der Datenträgerverwaltung wieder genauso wie im Post#6 aussieht.
Vergewissere Dich, dass in der Datenträgerverwaltung die Platte als Datenträger0 aufscheint
HxD Aufruf unter User mit Administratorrechten (oder per rechtklick - Ausführen als ...)
- Menü: Extras/open disk/physical disk/hard disk 2 (Häkchen bei "open as readonly" nicht entfernen)
========= sichern MBR+GPT Member2
- Menü: Edit/select block/start: 0 ; length: 600, 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... Ordner wählen und dateiname "MBRGPT2.bin"
- Menü: File/Close (es erscheint wieder die markierte Anzeige der hard disk) - Menü: Edit/Fill selection/hex values: 11/OK
- Menü: File/Save (schreibt es auf die Platte zurück)
- HxD beenden
============== Plattenwechsel : an den jMicron Port0 jetzt die Member1 (WCASJ1119641)
- Menü: Extras/open disk/physical disk/hard disk 2 (Häkchen bei "open as readonly" diesmal schon entfernen)
Überprüfen, ob Du auf der richtigen Platte gelandet bist:
in der Menüzeile muss rechts Sector [Eingabefeld] of 1953525168 stehen; wenn nicht - ABBRECHEN
Im Sektor 0 muss am Offset 1C0 der rot markierte Inhalt zu finden sein: 000000001C0 21 00 07 FE FF FF 00 08 00 00 00 A0 E0 E8 00 00 !..þÿÿ.....*àè..
wenn nicht, ABBRECHEN
========= sichern+ löschen MBR Member1
- 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... Ordner wählen und dateiname "MBR1.bin"
- Menü: File/Close (es erscheint wieder die markierte Anzeige der hard disk)
- Menü: Edit/Fill selection/hex values: 11/OK
- Menü: File/Save (schreibt es auf die Platte zurück)
- HxD beenden
Die Member2 (WCASJ1336241) steckt jetzt am JMicron, wird in der Datenträgerverwaltung allerdings unter "Datenträger1" (siehe Anhang).
Soll ich nun fortfahren wie geschrieben oder das folgendermaßen anpassen?
"- Menü: Extras/open disk/physical disk/hard disk 2"
P.S.: der JMicron steht momentan auf "Basic", die Festplatte wurde nicht als Bootmedium definiert & der ICH7R steht auf Raid (was aber wohl keine Rolle spielen sollte). Sollte ich hier noch was ändern damit die Platte als "hard disk 1" erscheint?
Wie alt ist diese Serie, 5 Jahre?
