Cache Drives unmountable


shaker
Go to solution Solved by Ford Prefect,

Recommended Posts

Hallo,
Ich hab ein Problem mit meinen Cache-Drives und weiß nicht mehr weiter. Folgendes ist passiert:

 

Mein System lief ohne Probleme und nennenswerte Ereignisse. Alles war online. Ich hab an ein paar Einstellungen meiner SMB shares gearbeitet. Dazu musste ich das Array dann auch stoppen.
In dem Moment, als ich das tat, verabschiedete sich eine meiner beiden Cache Drives aus Unraid. Wurde nicht mehr angezeigt.

Ich hab das Array wieder versucht zu starten, das klappte auch. Zunächst hat das gar nicht viel ausgemacht, läuft ja als Spiegelung. Aber dann gab es ein paar Fehler.
Ich habe zunächst mal den Mover manuell aktiviert und vom bestehenden Cache alles hochschieben lassen.
Soweit sogut.

 

Dann habe ich das System neugestartet. Keine Veränderung - Cache 2 war tot.

 

Ich habe das System ins Bios gebootet, um zu prüfen, ob dort die NVMe gefunden werden konnte. Das tat es auch, alles schien normal. Keine Änderungen durchgeführt.

Nochmal in Unraid gestartet. 

Nun sind beide Caches wieder da, grün, erkannt.

 

Aber leider sind nun BEIDE nicht mehr initialisiert und es zeigt die Meldung "Unmountable: No file system". Auf beiden.

Das ist nun ein riesen Problem, denn meine Docker sind auf den Drives. Diese sind nun gerade weg.

Kann sein, dass dies nicht 100% so eine gute Idee war, aber meine Informationen nach, sollte das ja machbar sein mit einem physischen Raid 1, oder? Ich dachte ja nie im Leben, dass 2 Probleme gleichzeitig auftauchen. 

 

Nun mache ich erst mal gar nichts, und frage hier nach. Verstehe gerade nicht, was da nun passiert ist. Im Prinzip hab ich genau GAR nichts gemacht, bis auf einen Mover Befehl und 2 Neustarts. WTF?

 

Hat jemand Ideen? 

Link to comment
16 minutes ago, shaker said:

Ich habe das System ins Bios gebootet, um zu prüfen, ob dort die NVMe gefunden werden konnte. Das tat es auch, alles schien normal. Keine Änderungen durchgeführt.

Nochmal in Unraid gestartet. 

Nun sind beide Caches wieder da, grün, erkannt.

 

Aber leider sind nun BEIDE nicht mehr initialisiert und es zeigt die Meldung "Unmountable: No file system". Auf beiden.

Das ist nun ein riesen Problem, denn meine Docker sind auf den Drives. Diese sind nun gerade weg.

...das riecht nach einem Hardware-Problem.

Dass die Docker "weg" sind ist eigentlich ja kein Problem, kann man ja mit einem Klick wieder neu erstellen...hast Du das appdata Verzeichnis auf Array ge-moved oder wäre das auch "weg" (das wäre evtl. zumindest ärgerlich).

 

16 minutes ago, shaker said:

Hat jemand Ideen? 

Hast Du im BIOS irgendwas verstellt, insbesondere ASPM / Power Modus für PCIe insbesondere?

Welche HW ist es genau...stell mal Deine Diagnostics hier ein.

Link to comment

Es gibt News. Hab nun noch einmal neu gestartet. Jetzt läuft es plötzlich wieder.
Beide sind wieder da. Die erste läuft normal, die 2. ist Teil des Pools.

 

Wird sie nun automatisch wieder aufgebaut / gebalanced, oder muss ich da was leisten?

 

Erst mal schauen, dass sich wieder alles normalisiert...

 

Aber ich habe dieses Topic entdeckt 

Das ist ja nun wirklich nicht sehr vielversprechend.

Ich sollte also mittelfristig an dem Setup was verändern, wenn ich auf der sicheren Seite sein möchte. 

Link to comment

Hallo nochmal.

 

Sorry, ich komme hier einfach nicht weiter. Mache alles nur noch schlimmer.

 

Ich hatte erneut viele Probleme mit den Cache Drives. Verstehe nicht, warum sie nicht sauber funktionieren. Errors werden keine angezeigt. Aber die Balance steht immer auf Single, nicht auf Raid1.

 

Am Ende dachte ich nun dran, den Cache aufzulösen und grundlegend neu zu erstellen.

Dazu wollte ich die Shares auf Cache "no" stellen und den Mover einsetzen und dann bei leerem Cache die NVmes neu aufsetzen.

 

Beim Einstellen auf "no" vom ersten Share "appdata" waren alle shares plötzlich weg. War das nun ein Denkfehler?

Nun geht eigentlich gar nichts mehr. Keine Shares, keine Docker, nur die Files sind noch auf dem Cache und dem Array.

Aber ich sehe nun den Weg nicht mehr. Kann ja nun nicht mal mit Krusader oder so die Daten manuell umziehen.

 

Kann irgendjemand helfen?

Link to comment
21 minutes ago, shaker said:

Dazu wollte ich die Shares auf Cache "no" stellen und den Mover einsetzen und dann bei leerem Cache die NVmes neu aufsetzen.

Beim Einstellen auf "no" vom ersten Share "appdata" waren alle shares plötzlich weg. War das nun ein Denkfehler?

...wenn Du mit diesen Einstellungen und dem mover spielst, musst Du vorher alle Services, die auf dem cachje Files nutzen beenden -> Docker und VM stoppen und unter Einstellungen die jeweiligen Dienste stoppen.

Dann erst kannst Du die Cache Einstellungen für die Shares machen und den mover einsetzen.

Link to comment

Ja das hatte ich gemacht.

Aber ich gehe davon aus, dass der Mover nie seinen Job machen konnte, weil mit dem Cache drive etwas nicht stimmt. 

Da gab es Meldungen wie canot write to cache - cache full.

Aber voll war es eigentlich ganz und gar nicht.

 

Nun stehe ich aber in einer Sackgasse. Weil die shares weg sind und ich nun nicht weiß, wie ich vorgehe, um das zu retten.

Link to comment
2 hours ago, shaker said:

Dazu wollte ich die Shares auf Cache "no" stellen und den Mover einsetzen und dann bei leerem Cache die NVmes neu aufsetzen.

Das ist schon Mal ein Denkfehler.

Bei "No" wird der betreffende Share vom mover komplett ignoriert. Wenn dann was auf dem Cache liegt, bleibt es da.

Zum verschieben muss "Yes" ausgewählt sein

Link to comment
  • Solution
3 hours ago, shaker said:

Nun stehe ich aber in einer Sackgasse. Weil die shares weg sind und ich nun nicht weiß, wie ich vorgehe, um das zu retten.

Aber wie Du sagst sind die Files noch auf dem Array und Cache.

Also sind die Disks gemounted....hast Du auch den SMB-Service gestoppt? Dann hast/siehst Du natürlich keine Shares mehr ;-)

 

Link to comment
Quote

Also sind die Disks gemounted....hast Du auch den SMB-Service gestoppt? Dann hast/siehst Du natürlich keine Shares mehr 

Also die Shares sind wieder da. Neustart hat geholfen. Vielleicht hatte der SMB-Service einen Fehler.

 

Quote

Das ist schon Mal ein Denkfehler.

Bei "No" wird der betreffende Share vom mover komplett ignoriert. Wenn dann was auf dem Cache liegt, bleibt es da.

Zum verschieben muss "Yes" ausgewählt sein

Danke, ja das stimmt. Hab sie nun auf "Yes" gesetzt und den Mover gestartet.

 

Also das Problem war, dass das Cache drive immer wieder nicht ordentlich gemountet hat.

Ich habe es nun mit dem Plugin unBALANCE leer geräumt, weil ich meine Docker nicht mehr starten konnte, und es per Mover meiner Meinung nach auch nicht richtig geklappt hat.

Dann habe ich den kompletten Cache neu aufgebaut.

Raid1 ist jetzt wieder aktiv und ist habe die shares zum Teil wieder auf "Prefer" gesetzt. Mover gestartet und jetzt hat er mir wieder alles herbeigeschaufelt.

 

Nun muss ich schauen, was alles noch läuft oder auch nicht. Docker usw. Aktuell ist das noch alles offline.

 

Danke schonmal.

Link to comment

Wollte hier noch kurz Rückmeldung geben über den Stand der Dinge.

 

Also seit dem Neubau des Caches läuft alles wieder.

Es ging gar nichts verloren, und alle Systeme konnten wieder anlaufen, als wäre nichts geschehen. Rettung hat also geklappt.

 

unBALANCE kann ich übrigens empfehlen, das hat mir sehr geholfen und wahrscheinlich auch datentechnisch den Arsch gerettet.

 

Ich habe mich aber gefragt, wie es eigentlich dazu kam.

Hierzu folgende Gedanken: Der Fehler ist passiert, als ich das Array gestoppt habe. Dort hat es irgendwas im System vom Cache zerschossen. Die NVMes konnten anschließend nicht mehr sauber gelesen werden und wurden auch nicht mehr als Raid1 erkannt.

Das hat sich angefühlt, als würde man während einem Zugriff ein Gerät vom PC entfernen, ähnlich beim abstecken einen USB Datenträgers.

 

Auf den NVMes laufen meine Docker, da gibt es eine InfluxDB und ioBroker mit meinem Smarthome. Da werden nun auch einige Dinge aufgezeichnet, oder eben überwacht usw.

Ist es möglich, dass wenn ich das Array abschaltet, dort ggf. in Schreibprozesse eingreife und diese dann gefährlich auf das Dateisystem reagieren könnten?

Wäre es sinnvoller erst manuell die Docker abzuschalten, dann das Array zu stoppen?

 

Ich kenne so eine Thematik auch von geschäftlicher Seite. Dort betreiben wir SSDs in einer Industrieumgebung in Hardware ohne USV im Dauerbetrieb. Damit dies möglich ist und auch bei Stromausfall eine Festplatte nicht zerstört wird oder Speicherzellen schädigt, schützen wir diese über spezielle Kommandos direkt in den Treiber vor den Speicherzellen.

 

Ich weiß nun nicht, wie das beim Abschalten eines Arrays bei Unraid läuft, und wie da mit laufenden Schreibprozessen umgegangen wird. Vielleicht weiß da einer mehr.

Beim nächsten Mal, werde ich jedenfalls mal vorsichtshalber auch erst die Docker stoppen.

Link to comment
12 minutes ago, shaker said:

Ist es möglich, dass wenn ich das Array abschaltet, dort ggf. in Schreibprozesse eingreife und diese dann gefährlich auf das Dateisystem reagieren könnten?

Wäre es sinnvoller erst manuell die Docker abzuschalten, dann das Array zu stoppen?

Das wäre auf jeden fall sinnvol.

Die Docker- und VM- Basisdienste können nur laufen/gestartet werden, wenn das Array läuft.

Andersherum führt der Stopp des Array auch dazu, dass Docker und VMs beendet werden müssen und die Dienste gestoppt werden müssen.

Wenn da Docker und VMs nicht drauf reagieren, kann es zu ungewollten Effekten kommen.

Link to comment
20 hours ago, shaker said:

Ich weiß nun nicht, wie das beim Abschalten eines Arrays bei Unraid läuft, und wie da mit laufenden Schreibprozessen umgegangen wird.

Wenn in Linux ein umount ausgeführt wird, wird ganz sicher vorher auch ein Page Flush von Linux gemacht. Alles andere wäre ja konzeptionell unsinnig und hätte schon massig Beschwerden resultiert.

 

20 hours ago, shaker said:

Damit dies möglich ist und auch bei Stromausfall eine Festplatte nicht zerstört wird oder Speicherzellen schädigt, schützen wir diese über spezielle Kommandos direkt in den Treiber vor den Speicherzellen.

Ihr habt einfach den Schreibcache der Datenträger deaktiviert, wobei das bei Enterprise SSDs nicht notwendig ist, da die bei Stromausfall ihren Cache automatisch wegschreiben. Problematischer ist da eher der Linux Page Cache, aber wenn der auch quasi inaktiv ist, ist auch das kein Problem.

 

20 hours ago, shaker said:

Die NVMes konnten anschließend nicht mehr sauber gelesen werden und wurden auch nicht mehr als Raid1 erkannt.

Willkommen in der Welt von BTRFS. Kurze Verbindungsprobleme und das RAID ist kaputt. Einzige korrekte Lösung: btrfs scrub und die Fehler korrigieren.

 

On 3/22/2022 at 11:43 AM, shaker said:

Am Ende dachte ich nun dran, den Cache aufzulösen und grundlegend neu zu erstellen.

Dazu wollte ich die Shares auf Cache "no" stellen und den Mover einsetzen und dann bei leerem Cache die NVmes neu aufsetzen.

 

Beim Einstellen auf "no" vom ersten Share "appdata" waren alle shares plötzlich weg. War das nun ein Denkfehler?

Böser Fehler. "No" deaktiviert nicht nur den Mover, sondern verbietet den Zugriff auf den Cache. Alle laufenden Container sind danach häufig korrupt, weil sie nicht mehr auf ihre Dateien zugreifen können und anfangen auf das Array zu schreiben, was dazu führt, dass Dateien mit dem selben Dateinamen aber unterschiedlichem Inhalt nun auf Cache und Array liegen. Check Mal über Shares > Ordner-Symbol > Location ob Dateien nun auch auf dem Array liegen. Prüfe auch ob nach Deaktivierung von Docker und VM der Mover wirklich fertig wird. Wenn nein Mover Logs aktivieren und Fehler prüfen.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.