Raid5 ist nach jedem Reboot inkonsistent

Hallo Raid-Spezialisten,

ich brauche Hilfe beim Thema Raid.

Ich habe ein TS-410 mit 4 Platten (4x "SAMSUNG HD154UI 1AG0").
Diese Platten sind zu einem Raid5 zusammengeschaltet.
Das NAS dient mir als Ablage der Filme, die ich mit der Dreambox aufnehme.
Pro Film gibt es eine Datei mit mehreren GB und ca. 5 weitere recht kleine Dateien (max. 5-10 MB).
Die Dreambox greift via NFS auf das NAS zu.

Mein Problem ist, dass nach *jedem* Reboot das NAS sein Raid nicht mehr mounten kann.
Und damit meine ich keine Reboots nach Stromausfällen o.ä. sondern einen ganz normalen Shutdown.

Ich muss mich danach auf der Konsole einloggen und einen manuellen fsck auf /dev/md0 laufen lassen.
Der läuft dann jedes Mal typischerweise mehrere Stunden.
Danach werden dann beim anschließenden Reboot die Platten wieder gefunden und gemountet.
Allerdings sagt mir das SystemLog immer noch, dass die Platten inkonsistent wären,
weshalb ich dann nochmal aus der Web-GUI heraus den fsck starte.
Danach kann ich das NAS dann nutzen.

Im laufenden Betrieb merke ich keine Probleme.
Aber beim nächsten Reboot kann ich mir sicher sein, dass die Platten wieder nicht gefunden werden.

Kann mir bitte jemand helfen dies wieder zu reparieren.
Ich kenne mich zwar mit Linux aus, bin bei Raid aber Anfänger und möchte keine Fehler machen.

Vielen dank im Voraus,
Quacksalber

Hm, ein guter Gedanke. Danke für den Hinweis.

Wie kann ich das herausfinden?
In den System Logs steht zumindest nichts drin...
An welcher Stelle finde ich in dem Qnap-System ein entsprechendes Log?

Zitat von "dr_mike"

Bei deiner Aussage

bin ich eigentlich davon ausgegangen, das dieser kleine Tip reicht.

Normalerweise stimmt das auch.
Allerdings sind meine Linux- / Unix-Kenntnisse schon ein paar Jahre alt und stammen von Workstations.
Die Eigenheiten gerade der Embeddedsysteme muss ich mir noch aneigenen.

Zitat von "dr_mike"

Code

lsof | grep MD0_

sollte dich erstmal weiterbringen.

lsof ist mir auch bekannt, damit sehe ich die derzeit geöffneten files.
Aber inwiefern hilft mir das dabei, während des Shutdowns zu sehen, wo es klemmt?

Ich habe lsof übrigens gerade mal laufen lassen (ohne Shutdown).
Es zeigt mir einen Haufen offener *.[tl]db-Files in MD0_Data/.locks.
Sieht so aus, als ob smbd da die Hand drauf hat.

Samba ist übrigens auf dem NAS auch aktiviert, da ich mit einem Windows-PC auch auf die Dateien zugreife.

Aber um ehrlich zu sein, bin ich damit noch nicht wirklich schlauer.
Stelle ich mich gerade blöd an, oder sehe ich den Wald vor lauter Bäumen nicht???

Danke nochmal für die Hilfe.

Zitat von "dr_mike"

Gezielt musst du nach solchen Sachen suchen, die durch zusätzliche Dienste (QPKG, IPKG) oder eigene Änderungen laufen und auf den Platten Dateien offen halten.

Das Argument kann ich nachvollziehen, aber ich glaube, damit kommen wir nicht weit.
Alle Zusatzdienste wie bspw. svn oder Xdove habe ich auf meinem anderen NAS istalliert.
Das TS-410 dient mir nur als blanker Fileserver.
IPKG ist da zwar drauf, aber nur um den MidnightCommander zu installieren.
Andere Erweiterungen sind nicht aktiviert.

Danke für den Hinweis.
Den Eintrag kannte ich noch nicht.
Ich werde mich da am Wochenende mal durcharbeiten.

So, ich habe wie in dem oben verlinkten Beitrag den Test auf die offenen Files gemacht.
Einmal mit fuser, wie im Originalscript verwendet, und einmal mit lsof anstelle von fuser.
Beide Tests waren ohne Befund, d.h. ich habe keine Dienste o.ä. welche den unmount verhindern.

Allerdings habe ich heute während einer Aufnahme (also während die Dreambox via NFS Daten auf das NAS geschrieben hat) gesehen, dass dmesg haufenweise Errors ausspuckt.

Am häufigsten kommt

rpc-srv/tcp: nfsd: got error -104 when sending 140 bytes - shutting down socket

Das lässt mich vermuten, dass auf meinem NAS beim Schreiben tatsächlich Inkonsistenzen in Dateisystem entstehen.
Stimmt diese Vermutung? Ist die gezeigte Fehlermeldung die Ursache für das inkonsistente Filesystem?

Ich habe mal Google dazu befragt, bekomme aber keine einheitliche Antwort.
Einen Eintrag habe ich dazu in den QNAP-Foren gefunden. Der berichtete, dass bei ihm das Einschalten des Caches das Problem beseitigt hat. Der Tipp bringt mich aber nicht weiter, da mein Cache immer eingeschaltet war.

Es "riecht" für mich danach, als ob die Ursache irgedwo in der FW (Kernel / nfsd / nfs-Konfig) zusuchen ist.
Bitte korrigiert mich, wenn ich daneben liege.

Derzeit habe ich meine bisherige FW (V3.6.1) mal auf die V3.7.3 aktualisiert und beobachte das Verhalten.
Falls das nicht hilft, werde ich es danach mit der V3.8.2 versuchen.

Ich bin mir ziemlich sicher, dass ich das Problem früher nicht hatte.
Dummerweise kann ich nicht genau sagen, bei welchen FW-Upgrade dies evtl. angefangen hat...

Falls jmd. die obige Fehlermeldung bei den QNAP-NAS schon gesehen hat, wäre ich für Hinweise dankbar.

Quacksalber

So, nur um diesen Thread zu einem Abschluss zu bringen:

Das FW-Update auf die V3.7.3 scheint die Problematik behoben zu haben.
Ich habe in der ganzen Woche nur einen einzigen nfs-Error im dmesg gesehen,
und das obwohl ich viele Testaufnahmen auf unterschiedlichsten Kanälen gemacht habe.

Auch ein Reboot des NAS hat ohne Fehlermeldung funktioniert.

Ich betrachte das Thema als erledigt.

Quacksalber