Feb 26

Mei, schkrich the fucking Crysis!

Vor einigen Wochen hatte ich ja zunächst mal die Idee, mein Daten-RAID zu vergrößern. Da der RIAD-Controller außerdem noch bei zwei Platten (teilweise massig) fehlerhafte Sektoren gemeldet hat, bin ich schnell zu K&M Eletronik hier vor Ort in München gewandert und habe zwei identische Platten der Serie SAMSUNG HE103UJ erworben und die defekten ausgetauscht.

DAS hätte ich mal besser bleiben lassen, denn mitten im Array-Rebuilding fiel die erste neue Platte aus. Und ich hatte eine 20h-Schicht am Rechner, während der ich ca. 80% der Daten retten konnte. War leider von Sonntag Abend bis Montag Nachmittag, also hatte ich einen ganzen Tag Verdienstausfall.

Die Katastrophenplatte hat mir K&M glücklicherweise anstandslos vor Ort ausgetauscht, ich musste lediglich ein paar Tage warten, bis die Platte den Weg vom Zentrallager in den Laden geschafft hatte. Die beiden “bißchen kaputten” Platten habe ich zum deutschen Samsung-Partner eingeschickt und vorgestern nach ca. 2 Wochen Bearbeitungszeit wiederbekommen. Juhu.

Ab in die Wechselrahmen und ran an den Controller. Schaden macht Klug, dachte ich mir, und habe die beiden Platten gleich mal einem Burn-In unterzogen. Wie übrigens auch schon der K&M-Austauschplatte.

UND WAS IS?!?!?

Der Controller hat die eine Scheißplatte gleich zweimal wegen Fehler gekickt. Das erste Mal gestern Abend um 23:30 (danke “audible alarm”, ich hatte schon gepennt), das zweite Mal laut Logfile und tausend Error-Mails um 4 Uhr nochwas. Zum Glück hatte ich den nervtötenden Piepsealarm gestern noch abgeschaltet.

Gerade läuft badblocks das dritte Mal an, aber selbst wenn es tatsächlich durchlaufen sollte, habe ich jetzt schon erhebliche Hemmungen, der Platte jemals irgendwelche Daten anzuvertrauen. Leider liefert kein Log brauchbare Fehlermeldungen, der RAID-Controller meldet nur einen “I/O error”, aber nix mit fehlerhaften Sektoren oder sowas. Also tippe ich auf den Plattencontroller.

Falls der dritte Lauf fehlschlägt, werde ich die Platte nochmal an einem anderen Port testen, aber ich vermute schon jetzt, daß ich die Platte kommende Woche mit Anlauf zurück zu EDC nach Kelsterbach treten werde. Und nochmal drei Wochen warte, bis der Garantietausch endlich abgeschlossen ist…

Der Controller loggt übrigens wie folgt:

Feb 26 04:35:02 capoeira kernel: [1962364.950527] rr232x:[0,2] completion error, flags=84
Feb 26 04:35:02 capoeira kernel: [1962364.950530]
Feb 26 04:35:02 capoeira kernel: [1962364.950539] rr232x:ATA regs: error 40, sector count f4f4, LBA low 4480, LBA mid 8e, LBA high 70, device 40, status 41
Feb 26 04:35:02 capoeira kernel: [1962364.950542]
Feb 26 04:35:02 capoeira kernel: [1962364.962581] rr232x:start channel [0,2]
Feb 26 04:35:02 capoeira kernel: [1962364.962615] sd 0:0:2:0: [sdj] Result: hostbyte=DID_ABORT driverbyte=DRIVER_INVALID,SUGGEST_ABORT
Feb 26 04:35:02 capoeira kernel: [1962364.962620] end_request: I/O error, dev sdj, sector 1148227200
Feb 26 04:35:03 capoeira kernel: [1962365.504998] rr232x:channel [0,2] started successfully

Das ein paarmal hintereinander, danach gibt er auf und das Log wird von badblocks zugespammed, das pro Sekunde zehntausende (!) Fehler beim Beschreiben des Device meldet. Zum Glück ist Linux schlau und sagt nur:

Feb 26 04:37:42 capoeira kernel: [1962524.884689] printk: 63681 messages suppressed.

Einen Kommentar schreiben