Nur mal so am Rande...
Tach Jungs (und Mädels)
vollkommen zusammenhangslos, aber nun eben trotzdem hier hinein: ich kann mich erinnern, dass das Gerücht umgeht, dass der Perc 5/I bei Crossflash auf die LSI-Firmware Arrays?/VDs? über 4TB inkonsistent macht.
Naja, ich habe dem nicht ganz so wirklich Beachtung geschenkt und mein RAID-5 Array vor einer Woche auf 4.092 TB erweitert. (Um ehrlich zu sein, ich hatte das total vergessen, dass mein Controller auf LSI geflasht ist. (Eigentlich habe ich das auch nur durch Zufall rausgefunden, weil der, von dem ich den gekauft hatte mir das nicht gesagt hatte). Dabei ist mir zuerst eine Platte aus dem RAID geflogen, beim Reconstruct mit einer neuen Platte gab es dann ein paar weitere Fehler in Form von "bad-blocks"
Ich habe mich ersteinmal total gewundert, weil die Platten nun nicht sooo alt sind (1.5y), aber naja, kann ja sein. Als ich dann ein Fehlerhaftes Rebuild fertig hatte (ein paar Bad-Blocks, was solls, hauptsche der Kram ist noch da, was will man machen: Platte fliegt aus dem Raid, und ich hab das Ding natürlich online, da kann ich die rausgeflogene Platte dann auch nicht mehr zu einen späteren Zeitpunkt zur Wiederherstellung gebrauchen) habe ich einen Consistency-Check laufen lassen, der schon wieder Fehler fand: dann bin ich stutzig geworden.
Hier das log des (ersten) Consistency checks:
Anhang anzeigen 11_22_2011.log.scheiss_beschränkung.doc Wen's interessiert, der nennt das File in *.log um und macht es mit MegaRAID auf.
Danach habe ich auf die Dell Firmware geflasht (gottseidank lag die noch bei mir rum, im Netz ist die grad nicht zu finden, hab ich das Gefühl) und ein neuen Consistency-Check gescheduled.
Jetzt hat der Consistency-Check die Fehler, die vorher unkorrigierbar waren korrigiert.
Hier das neue Log
Anhang anzeigen 11_22_2011_2.log.scheiss_beschränkung.doc
Im folgenden gehe ich davon aus
- Dass der Perc 5/I mit LSI firmware mein Array tatsächlich inkonsistent gemacht hat, sowohl beim Resizen als auch beim späteren Reconstruct, eventuell dadurch, dass er Lesefehler falsch interpretiert hat oder nicht korriegeren wollte
- Dass der Consistency check nach dem Fehlerhaften Reconstruct (von einer Fehlerhaften Quelle?) weitere Fehler hervorgerufen hat
- Dass dies an der (neuen?) LSI Firmware liegt in Kombination mit dem PERC 5/i
Ferner vermute ich:
- Das die Platten tatsächlich defekt waren, aber die Fehler eigentlich korrigierbar gewesen wären.
- Dass Fehler, welche durch das Resize und den Reconstruct eingefügt wurden nun bestehen bleiben, da ich ja zu mindestens einem Zeitpunkt keine Parity-Information mehr hatte (denn eine Platte war ja rausgeflogen)
- Dass die Fehler, welche nach dem Reconstruct durch einen weiteren Consistency-Check bemängelt/hervorgerufen wurden nun behoben sind, denn offenbar korrigiert die Firmware jetzt wieder anhand der Parity-Daten
Ich hatte auch den Speicher und die Kühlung im Verdacht, aber ich habe mir eine wirklich famose Eigenbaukühlung gebaut und habe guten Luftzug im Gehäuse, damit wird das Ding unter Vollast handwar. den Speicher habe ich vor den letzten beiden Consistency Checks getauscht, sie liefen also unter geleichen Vorraussetzungen. Zum Interpretieren der SAS Fehlermeldungen is mir folgendes Dokument in die Hände gefallen, danach hat alles ein wenig mehr Sinn gemacht:
Interpreting Unexpected Alert Codes
Also: nächstes mal in der umgekehrten Reihenfolge:
Log Checken -> Consistency Check -> Resize 
Zudem wurde mir klar:
- Dass ein Consistency Check einmal pro Woche das Risiko eines Unkorrigierbaren Fehlers, fernab von der Firmware-Geschichte, gerade beim RAID 5 erheblich verringert, besonders, wenn man auf die Daten nur sehr sehr selten zugreift oder gar schreibt
- Dass ein Array online zu behalten, nachdem eine Platte rausfliegt mir aufgrund des "stalls" die Möglichkeit nimmt diese Platte zum Rekonstruiren von Bad-Block später wieder heranzuziehen
Ich werde daher
- Auf Raid 6 umsteigen
- Oder das Array sofort schreibschützen, falls was ernstes passiert
Habe dann mal MSMFramework neustarten lassen, daraufhin musste ich bestätigen, dass MRMonitor ebenfalls neu gestartet werden muss. Tjo, hat aber letztlich funktioniert, danach wurde der Server wieder gefunden. Merkwürdig... Na ja, jetzt wissen wir ja, was dagegen hilft... 
Afaik habe ich den letzten "Schrei" rausgefischt, wenns auch nach einer alten Versionsnummer riecht. Irgendwie treibens die bei LSI mit den Versionsnummern ziemlich bunt, jedenfalls kann ich da kein System erkennen. Was hast du für eine Firmware/Treiber/SM-Kombi?
