Volume 1 - Abgestürzt; Diese Volume kann nicht verwendet werden.... ???

[deb10042]

Gibt es Einträge im Protokoll?

Nein, keine Einträge, die mich weiterbringen - s- Anhang. Also lediglich die Fehler-Einträge bei jedem neuerlichen Absturz des Volumes.

Sind die Smart Werte unverändert gut?

Auch hier, so weit ich das beurteilen kann, keine zusätzlichen, kritischen Erkenntnisse - s. Anlagen.

 

[ctrlaltdelete]

Nicht schön, welche DSM Version verwendest du?

 

[deb10042]

DSM 6.2.4-25556 Update 6
(ich habe ganz bewußt noch nicht auf 7... aufgerüstet, weil ich meine Photostation nicht aufgeben möchte)

 

[deb10042]

Jetzt habe ich eine Überlegung, bei der ich jedoch mangels Know How nicht weiß, wie man das umsetzt bzw. prüft:

Nachdem offenbar die Speicherbausteine nicht defekt sind (siehe gestrige Speichertests) und die Festplatten grundsätzlich eigentlich noch gut aussehen, interessiert mich der Zustand meines Dateisystems.

Ich erinnere mich, dass ich vor ein paar Wochen mal einen Fall hatte, bei dem es mir bei der Arbeit an Dateien der DS mit dem Windows Dateiexplorer nicht mehr möglich war, eine (oder vielleicht waren es auch mehrere) Datei(en) zu löschen. Leider weiß ich auch nicht mehr, ob und wie ich dieses Problem damals "behoben" oder umgangen habe. Vielleicht liegen diese vermeintlich kaputten Dateien immer noch dort, wo sie waren...
Das würde dann ja eigentlich auf irgendein Problem im Dateisystem hindeuten, oder?

Mein Gedanke wäre jetzt, mittels "irgendeiner" Befehlseingabe eine Liste aller Dateien auf der DS zu erstellen, in der Hoffnung, dass es bei "kaputten" Dateien irgendeinen Error (Read/Write) anzeigt.
Dann wüsste ich erst einmal, ob meine Vermutung richtig ist und könnte dann über den nächsten Schritt nachdenken, wie kaputte Dateien/Verzeichnisse auf der HDD korrigiert oder entfernt werden könnten.

Blöd nur, dass das Dateisystem zwar zugänglich, aber aufgrund des Ausstiegs des Volumes schreibgeschützt ist. Wie also eine ssh-Ausgabe in eine Liste umleiten?

Liege ich mit dieser Überlegung komplett daneben?

 

[ctrlaltdelete]

Du kannst über ssh versuchen das Volume zu reparieren, dazu neustart
ssh login
sudo -i cat /proc/mdstat
Das richtige Volume identifizieren
sudo btrfs check --repair /dev/???
wahrscheinlich: sudo btrfs check --repair /dev/md2

 

[synfor]

Fehlerfrei durchlaufende RAM-Tests (in Software) sind keine Garantie dafür, dass es keine Probleme mit dem RAM gibt. Mir sind über die Jahre verschiedene Threads mit instabilen PCs in verschiedenen Foren untergekommen. Die Symptome deuteten auf RAM-Fehler hin, die RAM-Tests lieferten aber selbst nach 24 oder 48 Stunden Laufzeit keine Fehler. Die Probleme wurden immer durch Austausch des RAM gelöst.

Nicht löschbare Dateien im Windows Explorer sind nicht zwangsläufig die Folge von Dateisystemdefekten. Es genügt, wenn irgend ein Programm beim Öffnen eine Datei lockt und wenn dann die SMB-Verbindung wegbricht, bleibt die Datei gelockt bis zum Löschen des SMB-Caches auf der DS, Restart des SMB-Services der DS oder Neustart der DS.

 

[ctrlaltdelete]

Wäre vielleicht ein guten Ansatz die DS mal nur mit dem original RAM zu betreiben und zu schauen was passiert.

 

[deb10042]

Wäre vielleicht ein guten Ansatz die DS mal nur mit dem original RAM zu betreiben und zu schauen was passiert.

Das habe ich vor etwa 2 h gemacht.
Kurz ging alles, aer dann kam auch wieder die Volume-Absturz-Meldung.
Daher kann ich vermutlich zumindest schon mal einen Defekt im Erweiterungsspeicher ausschließen, denn der liegt hier auf dem Schreibtisch.

 

[ctrlaltdelete]

Dann nur mit dem Kingston.

 

[deb10042]

Das hatte ich gestern gemacht: Kingston im Haupt-Slot -> es gab keinen Memoryfehler, aber führte auch wieder zum Volume-Absturz.
...aber gut, da der Kingston hier rumliegt und definitiv nicht der Übeltäter zu sein scheint, schiebe ich ihn jetzt nochmal in den Erweiterungs-Slot und lasse das 2 GB Modul weg. Wenn dann wieder der Absturz kommt, dürfte klar sein, dass die RAM-Module nicht schuld sind.

... paar Minuten später:
DS mit Kingston im Erweiterungs-Slot ist hochgefahren und sofort ist das Volume auch wieder abgestürzt.

Also, demnach liegt es meiner Meinung nach nicht am RAM.
Jetzt bin ich ratlos

 

[deb10042]

Habe beide RAM-Module wieder drin.
Ich war gestern am Abend zu gestresst von der ganzen Sache und zu allem Überfluss ist mir beim Umstecken der Festplatten eine aus der Hand gerutscht und etwas unsanft auf dem Schreibtisch aufgekommen. Das hat mir erst einmal den Schweiß auf die Stirn getrieben.
Trotzdem habe ich beide Platten auch wieder eingeschoben und siehe da, die Kiste fuhr nach etwas gutem Zureden beim Dritten Anlauf auch wieder hoch.
Daraufhin gab es im Speicher-Manager ein etwas anderes Bild:
- das Volume stand nicht auf "Abgestürzt" (obwohl es ja im wahrsten Sinne des Wortes abgestürzt ist )
- es wurde angezeigt, dass sich der Zustand der Speichermedien/Partitionen verschlechtert hätte
- die HDDs wurde dennoch beide als i.O. angezeigt
- auf einmal war eine Option "Reparieren" verfügbar, die es vorher nicht gab.

Ich habe dann auf "Reparieren" geklickt und nun ist ein Prozess in Gang, der quälend langsam voranschreitet. seit gestern Abend um ca. 18 Uhr werkeln die Platten (mit eher minimaler Geräuschkulisse) vor sich hin und ich schaue seit Stunden auf die Meldung "Prüfung die Konsistenz der Parität xy%".
Das dauert noch ewig, denn er ist derzeit trotz Nachtschicht erst bei 70%.

Aufgrund des Missgeschicks mit der Platte ist mein Zutrauen in "Reparaturversuche" gerade etwas am unteren Totpunkt.
Vorsichtshalber habe ich mir deswegen gestern gleich mal zwei neue Platten bei WD bestellt.
Und weil der Frust so groß war, gleich auch noch eine neue Kiste...

 

[Thonav]

Fühle mit Dir, aber ich kann mir sehr wohl vorstellen, dass Du im Anschluss ein besseres Gefühl hast!
Was ist es denn für eine neue Kiste geworden? Und - falls Du beim Einrichten Fragen hast, so stell sie doch kurz im Forum.
Grüße und alles Gute!

 

[deb10042]

Eine DS720+ und zwei WD Red Plus à 12TB.

Das gibt mir dann hoffentlich genug "Luft", mich dann später noch weiter um die DS718+ zu kümmern, wenn das System erst einmal wieder "rennt".

 

[its]

@deb10042: Mal ein ganz anderer Ansatz, lässt du deine Festplatten in den Ruhezustand nach x Minuten versetzen?
Wenn ja, schalte das mal aus!

 

[deb10042]

Nein, die Platten gehen bei mir nicht schlafen.

 

[Benie]

Wenn ja, schalte das mal aus!

Da würde mich interessieren mit welchem Hintergrund er das machen soll ? Warum dss Volume dann nicht abstürzt? oder Vorteil?

 

[its]

@Benie: ich hatte hatte es schon bei 2 Verschiedenen DS erlebt (zum Glück nicht meine eigenen), dass die Festplatte nach dem Aufwachen das Volume zum Absturz brachten und Speicher-Manager & Co aber keine Unauffälligkeiten zeigten. Mit einem Neustart der jeweiligen DS sah alles erst mal wieder OK aus, bis zum nächsten aufwachen der HDDs bei Zugriff darauf. Mit abschalten des Ruhezustands für die internen HDDs ist das Problem nicht mehr aufgetaucht und seit dem gab es keinen Absturz der Volumes.

 

[Benie]

Danke, ich wollte den Hintergrund kennen, da ich HDDs habe die seit über 9 Jahre in den Ruhezustand gehen und ich bisher nie Probleme hatte. Allerdings wenn es nicht als pauschale Betrachtung zu sehen ist, sondern gerade hier im Zusammenhang gesehen wird, kann das zumindest ein Ansatz Richtung Lösung sein.

 

[deb10042]

Ich habe jetzt drei Tage und Nächte "Reparaturen" über beide Festplatten laufen lassen. Nach Abschluss werden beide Platten immer wieder, genauso wie vorher, als "In Ordnung" angezeigt. Auch die SMART-Werte zeigen keine Verschlechterung bei den Platten. Ich schließe also mittlerweile aus:
- Plattendefekt
- Speicherdefekt
Bleibt eigentlich nur noch das Dateisystem und das Betriebssystem selbst. Das führt mich wieder zurück zu meinem Gedanken aus dem Post #64.
Hat jemand Erfahrung damit, solchen Fehlern mittels Kommandozeilen-Befehlen auf die Spur zu kommen?
(Irgendwie kann ich das immer noch nicht so richtig glauben, dass ein System, das anscheinend von der Hardware her in Ordnung ist und auf das großteils auch zugegriffen werden kann, "platt gemacht" werden muss, ohne herausfinden zu können, woran es eigentlich liegt... und dann eine Reparaturmöglichkeit an evtl. defekten Dateien wahrnehmen zu können...)

 

[synfor]

Meinen Beitrag hast du aber schon gelesen? Ich tippe nämlich trotzdem aufs RAM. Oder dein System hat sich Bitrot eingefangen.