QNAP bootet nach Stromausfall zunächst nicht mehr, dann aber doch

  • Hallo,


    eigentlich wollte ich das Verhalten bei Stromausfall eher mal unter Laborbedingungen testen. Leider hat mich die Praxis 2x eingeholt. Aktuell hab ich das QNAP nicht an der USV hängen, und der Sturm tat sein übriges. :(


    Dabei ist mir etwas passiert, was sich kurioserweise durch mehrstündiges Warten von selbst behob. Vielleicht stößt ja einer von Euch auch darüber.


    Also: Während ich gerade am Kopieren von Dateien vom externen Laufwerk auf das interne Dateisystem war, gingen die Lichter aus. Strom weg. Das nahm ich zum Anlass, hinterher mal das Dateisystem zu prüfen. In der Tat blieben Inkonsistenzen zurück, und zwar nicht nur in den Dateien, die gerade geöffnet waren (das wäre i.O.), sondern auch in den ext4-Metadaten. Gefühlt war nix dramatisches dabei. Lies sich alles auch durch den "Dateisystemcheck" reparieren. Darf aber bei einem Journaling-Filesystem nicht passieren, deshalb werde ich mal ein Ticket erstellen. Vielleicht klappen ja manche Syncs nicht richtig. Vom ext4 über LUKS, LVM2, DRBD und RAID ist es ja ein etwas längerer Weg bis zur Platte runter. Ob das nun etwas mit dem folgenden Verhalten zu tun hat, weiß ich nicht.


    Interessant war nun, dass ich das System nach dem Stromausfall genau einmal hochfahren konnte, und dann aber nicht mehr. Beim Booten hing er sich weg. Es stand auf dem Display:


    QNAP_HANGS.png


    Kein Netzwerkzugriff, kein Reset über On/Off-Knopf möglich. Nur 5-Sekunden-On/Off-drücken-Reset ging. Also tot.


    Ich habe noch 1-2 Reboots probiert mit dem gleichen Ergebnis. Frustiert ging ich weg von der Anlage ... und ließ sie, warum auch immer, einige Stunden laufen. Und danach probierte ich noch einen Reboot - und der klappte! Das war mir unerklärlich. Bis der zweite Stromausfall kam. Da ist das gleiche wieder passiert! Ich war wieder am kopieren, als es geschah. Einmal booten ging wieder, dabei Filesystem reparieren usw., dann Neustart - und hängt schon wieder! Nun lief es wie der Zufall so will erneut einige Stunden von alleine. Und auch danach klappte der Neustart wieder. Crazy :)


    Nun habe ich eine Theorie, die ich aber nicht prüfen möchte: Nach dem Stromausfall begann das RAID ein resync. Der dauert ja bekanntlich. Kann es sein, dass es nicht bootet, falls das RAID nicht in snyc ist? Und dass er im Hintergrund aber weitersyncht, und irgendwann fertig ist, und danach dann der Reboot klappt? Dagen spricht, dass ein resyc bei mir so 5-6 Stunden dauert bei maximaler Geschwindigkeit. Und ich will nicht recht glauben, dass ich beim zweiten Stromausfall so lange schon gewartet hatte. Aber ausschließen kann ich es nicht. (EDIT: Kaum hatte ich es geschrieben, fand ich raus, dass er mit dem Sync erst bei 25% ist. Also warum klappt der Reboot plötzlich doch? @Gummiente: Vielleicht weil ich das Display ausgeschaltet hatte und es nun an ist?)


    Falls also jemand auf das gleiche Problem stößt: Nicht gleich aufgeben, d.h. nicht gleich alles neu aufsetzen. Manche Probleme erledigen sich durch Warten?





    VG

    Holger


    Anhang: Dateisystemfehler - betroffen sind offenbar nur Metadaten der Files, die gerade kürzlich geschrieben wurden, sowie das QTS-Event-Log, was ja vermutlich ebenfalls schreibend geöffnet war. Insofern alles wie es bei einem Non-Journaling-Filesystem zu erwarten wäre. Nix tragisches. Das Journaling sollte aber ja dazu da sein, dass auch diese Metadaten konsistent bleiben. Und das hat nicht funktioniert. Kennt sich jemand aus, ob man da irgendwas einstellen kann, damit das Journal auch nach unten durchgetragen wird? In alten Linuxen war das doch glaube ich nicht alles auf Robustheit voreingestellt, sondern auf Performance. Ich dachte aber, das wäre Geschichte?


    Errors_Stromausfall1.txt

    Errors_Stromausfall2.txt

    2 Mal editiert, zuletzt von Sumpfdotter () aus folgendem Grund: Typo, RAID-Theorie widerlegt (durchgestrichen), Display-Theorie ergänzt, Gummientenlink ergänzt ;-)

  • Vielleicht, weil dann die Systempartitionen wieder resynct waren?

    Hm, stimmt, guter Ansatz. Obwohl ich mich zu erinnern glaube, dass ich mir vor dem Boot mit cat /proc/mdstat das Raid angesehen hatte, und nur die Datenpartition war noch nicht in sync. Das spräche ein wenig dagegen.