bjoern3003

Kleines Update. Gestern alle VMS und Container gestoppt, mit dem Mover alle Daten auf das Array verschoben, Dateisystem gewechselt, Formatiert, Daten mit dem Mover zurück verschoben, alles wieder hochgefahren. Läuft. Danke euch.

Ist der Wechsel des Dateisystems so problemlos möglich? Ist das die einzige Möglichkeit dem Problem aus dem Weg zu gehen? Hierbei handelt es sich nur um eine einzelne Cache Platte. Kein Raid.

Hi, ich habe auf meiner Cache Platte langsam ein Speicherplatz Problem. Nun könnte man sagen, was solls, hol ich halt ne größere NVME. Aber ich vermute, dass ich das Problem damit nur zeitlich verlagere. Ich konnte das Problem im Bereich cache/system/docker/btrfs/subvolumes ausmachen. Bei derzeit 17 installierten Containern habe ich 207 subvolumes, welche insgesamt 103GB an Speicherplatz einnehmen. Ich habe schon davon gelesen, dass wohl Docker in Verbindung mit BTRFS manchmal zu solchen Problemen kommen kann, dass verwaiste Volumens (z.b. auch durch Updates) gar nicht gelöscht werden. Daher habe ich nun auch mal versucht, dieses Script laufen zu lassen: https://github.com/SpaceinvaderOne/Unraid_check_docker_script Das hat zwar was gefunden, aber lediglich weniger als 330MB Anbei eine Statistik aus dem Script: ################################################################################## List of Image, Container and docker volume size. ################################################################################## There are 17 Images taking up ......12.72GB There are 17 Containers taking up ......390.1MB There are 57 Local Volumes taking up ......645kB There are 0 Build Cache taking up ......0B Bedeutet im Umkehrschluss für mich, dass dort noch jede Menge alter Images liegen müssen, die gar nicht mehr benötigt werden?! Habe hier https://github.com/moby/moby/issues/9939 nun noch folgenden Befehl gefunden. Kann man den bedenkenlos mal absetzen? docker system prune -a --volumes Habt Ihr weitere Ideen oder Ansätze für das Problem?

Update: Die anderen beiden gelben Zeilen musste ich auch noch von rechts nach links korrigieren, da das Netzwerk nicht mehr funktioniert hatte.

Ich habe seit heute ein nerviges Problem, dass ich glücklicherweise durch ein Backup meiner VM XMLs "finden konnte. Ich habe eben wegen neuer RAM und CPU Zuweisung eine Windows VM neustarten müssen. Plötzlich bekomme ich nur noch den Konsolen Bildschirm von Unraid, wie wenn der Boot Sektor defekt ist. Ich habe also die XML meines Backups eingespielt und die VM bootet wieder normal. Wieder runtergefahren, über das UI von Unraid nochmal CPU und RAM zugewiesen, wieder kein Bootvorgang. Wieder altes XML rein und nur die VM im UI ohne Änderung abgespeichert. Startet auch nicht. Also die XMLs mal verglichen. Es sind tatsächlich NACH dem abspeichern Änderungen vorhanden. Eine Änderung unter anderem ist diese: Wenn ich die ersten beiden gelben Zeilen links mit denen aus dem rechten XML ersetze, fährt die VM wieder hoch. Aber ich darf den XML Modus nicht verlassen. Wenn ich dann wieder in den UI Modus geht, macht er mir die XML wieder "kaputt". Kann mir da jemand helfen und sagen, was das ist? Ich verstehe es nicht so recht.

Die MariaDB läuft im Docker.

Die "performance" sehe ich in der Auslastung von unraid und in der Bedienung. Alles sehr träge. Query setze ich kein spezielles ein. Da läuft halt Home Assistant drauf. Die komplette Datenbank ist einfach lahm.

Habe die 10GB Datenbank nun testweise mal in eine lokale Datenbank kopiert. Dort wird das Query in unter 1 Sekunde ausgeführt. Ich führe nun mal ein optimize aus, und gucke, was das bringt. Bin aber gerne für Ideen oder Lösungen offen.

Moin, ich suche das folgende Problem mal im Docker/Unraid Bereich, da mir diese Probleme auf meiner vorherigen Windows Kiste nie aufgefallen waren. Habe Home Assistant laufen (eigene VM) mit einem MariaDB Docker Container für die Datenspeicherung (recorder). Grundsätzlich funktioniert das Setup auch, jedoch habe ich einige Queries, die nun über 12 Sekunden Ausführungszeit brauchen. Ja, die DB ist nicht gerade klein, aber der Server ist eigentlich Potent genug und vorher auf der schwacheren Windows Kiste liefen die Abfragen und das speichern in die DB auch irgendwie (deutlich) schneller. DB Größe ca 10GB AMD EPYC 3151 4-Core @ 2700 MHz Arbeitsspeicher: 64 GiB DDR4 Multi-bit ECC Anbei auch mal meine Settings vom Container und dem appshare Verzeichnis. PS: Die Abfrage über HeidiSQL dauert ebenfalls ca. 12 Sekunden.

Korrekt... Gestern kurz "gekotzt" aber das Leben geht weiter. Rückgängig machen kann ich es jetzt nicht mehr - nur draus lernen und so bin ich nun an einer besseren Backupstrategie dran und achte genauer drauf, dass die Pfade korrekt gesetzt sind. Ebenso werde ich nun nach ersten Tests immer mal mindestens 1x den Host komplett neu starten, um zu sehen, ob danach noch alles da ist.

Das Leute immer hinterher drauf hauen... 😄 Denkst, du , dass ist mir hinterher nicht auch selber klar? Ich habe doch bereits oben mir selber die Schuld gegeben. Frage mich immer, ob die Kommentare dieser Leute nur zum Beiträge sammeln dienen oder was damit erreicht werden soll. Bekanntlich lernt der Mensch aus Fehlern. Das habe ich - meine Hoffnung war nur, dass die Dokumente vielleicht noch irgendwo liegen.

Okay, das Problem konnte ich lösen, indem ich in der sqlite DB die Inhalte von filename um _old ergänzt habe. Da liegt ein unique index drauf und er zählt wohl neu hoch, wenn die Dateien nicht gefunden werden.

Super - neu natürlich nicht mehr möglich, da die Dokumente logischerweise zum Teil gar nicht mehr existieren. Eigene Dummheit. Aber wie kommt denn dann trotzdem beim Importieren der oben genannte Fehler Zustande? Ich würde trotzdem gerne die Datenbank behalten, da zumidnest der Index mit der OCR Erkennung vorhanden ist und im Zweifel die Dokumente immerhin als Text da sind.

Nein, das war es nicht. Ich habe die Docker container als Verzeichnis (nicht als docker.img) in user/system/docker/installed liegen und alles nach *.pdf durchsucht. Alle möglichen pdf gefunden, aber leider keine der, die ich mit paperless-ngx importiert habe 😞

ne, die Daten sind weg - vermutlich weil ich dann eben vorschnell den Pfad auf mein mnt/usr/ Verzeichnis gesetzt habe. Damit zeigt das media Verzeichnis ja auf einen Unraid Ordner. Verdammte Kacke...