COLOSSUS
AdministratorGNUltra
|
Erstaunlich!
Zuerst dumpen (bzw. die Daten abgreifen), dann kann man ueber einen fsck nachdenken. Der ganze Rest auf dem Block-Level ist eigentlich irrelevant. Ich wuerde die Disken nacher trotzdem auf jeden Fall mit badblocks martern.
|
EG
thinking with portals
|
Du hast ja einiges aus den logs rausgelesen...irgendwo muss ja ein Grund für diesen Vorfall da sein... Mir is schon klar, was genau du da rausinterpretiert hast, nur schließen deine Interpretationen in meinem Verständnis das momentane Verhalten des Raids aus. Werd auf jedenfall badblocks nacher laufen lassen. Momentan hab ich 1h fürs copy vom raid, weil die Dateien logischerweise alle recht klein (Fotos) sind. edit: Va. ist alles clean und persistent...es KANN...DARF doch garnicht persistent sein?? !?  sdf ist - wie du schon gesagt hast - über 200 Minuten vorher rausgefallen.
|
COLOSSUS
AdministratorGNUltra
|
Also wenn ich bei meinem Array eine Platte auch nur kurz rausziehe, hat das einen vollen Resync zur Folge. Keine Ahnung, was es da bei dir gezaubert hat - vielleicht beinhaltet dein Superblock andere Informationen, oder du hattest beim write intent bitmap mehr glueck als ich, oder...
Dass dein Array trotz eines subsequenten mdadm --create wieder/noch da ist, kann ich mir nur so erklaeren, dass dieser Aufruf mit einer mdadm-Version passiert ist, die per default nicht mehr 0.90er Superblocks, sondern hoeher versionierte Superblocks (die sich je nach genauer Version physisch wo anders auf den Member Devices befinden als die 0.90er-Variante) geschrieben werden - und dann durch einen gluecklichen Umstand (bzw. den Kernel-Auto-Init, welchen es nur mit 0.90er-Superblock-Arrays gibt) dein original-Array wieder hochgekommen ist.
|
EG
thinking with portals
|
Here it comes again...ich verstehs ned? Es fängt an mit einem USB-Fehler, dann ein Problem am port, nur diesmal konnte der Fehler wohl korregiert werden? Kanns sein, dass das Mainboard Probleme macht? click hereedit: More big bad voodoo...hängt die Northbridge? click hereedit2: mdadm --detail /dev/md0 verursacht den trace edit3: Was mir noch einfällt...ich hab in den letzten Tagen mal ein Update auf 2.6.32-25 gemacht... edit4: Nach jeder Menge rumrprobieren und booten mit dem 2.6.32-24 hab ich mal einfach die Kabel im Server gecheckt...scheinbar war da wirklich was halblocker/habldran auf einer der Festplatten... Jedenfalls läufts MOMENTAN wieder...mal sehn was noch kommt.
|
EG
thinking with portals
|
Sodala hab ein kleines Update auf der Jagd nach möglichen Fehlerquellen: Hab auf allen Platten badblocks laufen lassen mit folgendem Ergebnis: sdb - 0 sdc - 0 sdd - 97 sde - 505 sdf - 559 Die Zahlen entsprechen fehlerhaften Blöcken. Außerdem im dmesg Output jede Menge Sense Errors, zu denen ein Bekannter von mir sagt, dass er diese im Zusammenhang mit schlechten SATA-Kabeln bzw. schlechten Kontakten kennt. Wäre für mich logischer, als dass 3 Platten fast gleichzeitig anfangen zu sterben. dmesg als txt-file...das mit den code tags klappt wohl noch immer nicht: click hereWerd mal versuchen das Kabel einer fehlerhaften mit dem einer funktionstüchtigen zu tauschen und badblocks nochmal laufen zu lassen. Unterm Strich hab ich jetzt alle relevanten Daten vom Raid retten können, das sich mittlerweile nicht mehr mounten lässt, weil das Filesystem von Platte #5 (sdf) wohl jetzt defekt ist. fdisk erkennts jedenfalls nicht mehr. Ist leider so gekommen, als das Raid angefangen hat zu recovern. Wenn noch jemand Ideen hat, wie man der Ursache besser auf den Grund gehen kann bin ich für Vorschläge offen. edit: Gibts eine Möglichkeit festzustellen welches Device auf welchem SATA-Port hängt? Hab das Gefühl, dass die nicht in der richtigen Reihenfolge draufhängen...
|
COLOSSUS
AdministratorGNUltra
|
edit:
Gibts eine Möglichkeit festzustellen welches Device auf welchem SATA-Port hängt? Hab das Gefühl, dass die nicht in der richtigen Reihenfolge draufhängen... Der Edit war mir nicht aufgefallen. Die Ausgabe von hdparm -i /dev/sdX mit den Seriennummern auf den Platten selbst korrelieren. Prinzipiell ist es eine schlechte Idee, von einer bestimmten, deterministischen Enumerierung von Devices auszugehen. Als Loesung fuer dieses nicht ganz triviale Problem bleibt nur ein Satz udev-Regeln, die es aber bei den meisten Distros eh von Haus aus gibt (/dev/disk/by-id/ etc. - kann sich aber nach einem BIOS-Update bspw. auch aendern, mit genuegend Pech).
|
EG
thinking with portals
|
lshw war btw. die Lösung 
|
Anmeldung