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...

Hi, ich hoffe, ihr könnt mir helfen. Meine Dokumente in Paperless-NGX sind (ich vermute nach einem Update des Docker Containers) einfach weg. Also die Datenbank scheint noch intakt, da ich in der UI die Dokumente getagged sehe, allerdings ist das Vorschaubild nicht da, ich kann nichts herunterladen und keine der Dokumente einsehen. Versuche ich ein neues Dokument zu importieren, kommt ein riesen langes Log. [2024-04-10 19:26:14,030] [ERROR] [paperless.consumer] The following error occurred while storing document Report_001027.pdf after parsing: UNIQUE constraint failed: documents_document.archive_filename Traceback (most recent call last): File "/usr/local/lib/python3.11/site-packages/django/db/backends/utils.py", line 89, in _execute return self.cursor.execute(sql, params) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/django/db/backends/sqlite3/base.py", line 328, in execute return super().execute(query, params) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ sqlite3.IntegrityError: UNIQUE constraint failed: documents_document.archive_filename The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/usr/local/lib/python3.11/site-packages/asgiref/sync.py", line 327, in main_wrap raise exc_info[1] File "/usr/src/paperless/src/documents/consumer.py", line 725, in try_consume_file document.save() File "/usr/local/lib/python3.11/site-packages/django/db/models/base.py", line 814, in save self.save_base( File "/usr/local/lib/python3.11/site-packages/django/db/models/base.py", line 877, in save_base updated = self._save_table( ^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/django/db/models/base.py", line 990, in _save_table updated = self._do_update( ^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/django/db/models/base.py", line 1054, in _do_update return filtered._update(values) > 0 ^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/django/db/models/query.py", line 1231, in _update return query.get_compiler(self.db).execute_sql(CURSOR) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/django/db/models/sql/compiler.py", line 1984, in execute_sql cursor = super().execute_sql(result_type) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/django/db/models/sql/compiler.py", line 1562, in execute_sql cursor.execute(sql, params) File "/usr/local/lib/python3.11/site-packages/django/db/backends/utils.py", line 67, in execute return self._execute_with_wrappers( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/django/db/backends/utils.py", line 80, in _execute_with_wrappers return executor(sql, params, many, context) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/django/db/backends/utils.py", line 84, in _execute with self.db.wrap_database_errors: File "/usr/local/lib/python3.11/site-packages/django/db/utils.py", line 91, in __exit__ raise dj_exc_value.with_traceback(traceback) from exc_value File "/usr/local/lib/python3.11/site-packages/django/db/backends/utils.py", line 89, in _execute return self.cursor.execute(sql, params) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/django/db/backends/sqlite3/base.py", line 328, in execute return super().execute(query, params) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ django.db.utils.IntegrityError: UNIQUE constraint failed: documents_document.archive_filename Mein erster Fehler, den ich eben gesehen habe, war, dass ich das media Verzeichnis nicht in ein Verzeichnis auf unraid verlinkt habe, sondern offensichtlich im Docker belassen habe?! Aber selbst als ich den media Pfad eben nach /mnt/user/appdata/paperless-ngx/media verlinkt habe, wurde das pdf zwar dort abgelegt, aber der Error oben kam immer noch. Es wäre ein riesen Desaster für mich, wenn jetzt alle Dokumente weg wäre 😞 Ich hoffe, ihr könnt mir noch helfen.

Das verstehe ich. So wie ich den "appdata" Ordner aber verstehe, sind eben dort nur die Daten gelagert, die innerhalb der Docker Container verwendet werden. Also nicht der Container selber, sondern die gemounteten Verzeichnisse. Eben dieser wäre dann doch falsch konfiguriert?! Die Docker Container selber liegen Standardmäßig unter: /mnt/user/system/docker/installed/

Ich habe mal eine Verständisfrage. das appData, domains und system Verzeichnis ist bei mir wie folgt konfiguriert Das sind imho die Standard Werte. Wissentlich habe ich da nichts verändert. Nun ist es so, dass mein Cache Laufwerk langsam voll läuft. Idealerweise sollte es ja so sein, dass alles auf der HDD liegt und die häufig benötigten Daten im Cache liegen und der Mover alles wieder zurück auf die HDD schiebt. So mein Logisches Verständnis hierzu. In dem Fall hier macht er das aber doch genau NICHT, oder? Er schreibt nun alles auf die Cache Platte, bis diese voll ist. Müsste nicht eigentlich die Mover Aktion genau anders rum sein?

Eigentlich nicht, denn ich habe die Daten dann Lokal liegen und der synchronisiert im Hintergrund. Mag sein, dass es tatsächlich länger dauert, aber ich bekomme davon produktiv nichts mit. FTP geht wiegesagt nicht, da ich die Daten physisch oder als Netzlaufwerk lokal erreichbar haben muss.

Das ist vom Workflow leider keine Lösung. Produktiv ist was anderes. Ich teste jetzt mal eben Nextcloud als Docker mit einem lokalen Syncronisierungsclient.

Es geht mir auch insbesondere um das schreiben. Stimmt bei großen Dateien fällt es nicht auf und ist auch "egal". Gerade musste ich wieder rund 32k Dateien mit gesamt 200MB übertragen. Das hat ne gute Stunde gebraucht. Gibt es da keine Alternativen?

Ich habe tag täglich damit zu tun, eine große Anzahl an kleinen Dateien von meinem Arbeitsplatz (Windows) zu meinem Unraid System zu kopieren. Dieser Transfer dauert leider mitunter einige Stunden. Mit steigender Anzahl an Dateien dauert es umso länger. Aktuell läuft noch KEINE paritätsplatte mit. Es wird auch erstmal alles auf der NVME Cache Platte gespeichert und später mit dem Mover auf die große HDD kopiert. Große Dateien einzelne Dateien nutzen die kabelgebundene 1GB Netzwerkverbindung voll aus. Gibt es Möglichkeiten, ohne auf irgendwelche Tools Drittanbieter zu wechseln, die Geschwindigkeit zu erhöhen. Ich brauche für diverse Programme die Möglichkeit, die Freigaben auch als Netzlaufwerk anzusprechen.

Danke... kann es sein, dass das Plugin genau das schon erfüllt, ohne irgendwas eingestellt zu haben? Mein spontaner Test gerade konnte das Problem nicht erzeugen. Plugin ist nur installiert und nichts weiter eingestellt.

Naja, einfach in den Settings der VM das USB Gerät aktivieren.

Noch ein Feedback: Die Windows VM hat bei mir auch keinen nennenswerten erhöhten Stromverbrauch verursacht.