Cache-Laufwerk löschen bzw. auf zfs umstellen (6.12.0-rc3)

[DerTom]

Hallo zusammen,

ich nutze die Version 6.12.0-rc3 und bin auf die Idee gekommen, mein Cache-Laufwerk zu erweitern und auf zfs umzustellen. Dies ist zzt. eine einzelne nvme-ssd mit btrfs als Dateisystem.

In dem thread zu 6.12.-rc2 war eine Anleitung aufgeführt, wie das alte cache-Laufwerk geleert werden kann, um dann anschließend den alte Cache zu löschen. 

Mittels 'find /mnt/cache/ -depth | /usr/local/sbin/move -d 1' kann ich nun seit Tagen sehen, wie einzelne Dateien aus div. subvolumes des Ordners 'btrfs' angefasst werden - ein Vorgang, der nicht enden will. 

Komisch ist m. E. auch, dass die Cache-nvme nur mit 208GB belegt, gleichzeitig aber meine Datendisk 1 nun um beinahe 1 TB zusätzlich belegt ist. Andere Prozesse laufen nicht (VMs und Docker sind deaktiviert).

Ist dieses Verhalten normal? Was sollen die ganzen btrfs subvolumes auf der Datendisk 1, die mit xfs formatiert wurde? Kann ich den Ordner btrfs unter 'system' nach dem Kopiervorgang löschen?

Viele Grüße!

[saber1]

Warum nicht einfach wie hier beschrieben vorgehen:

https://wiki.unraid.net/Manual/Storage_Management#Backing_up_the_pool_to_the_array

 

Link zu den Manual's generell:

https://wiki.unraid.net/Manual

[DerTom]

29 minutes ago, saber1 said:

Warum nicht einfach wie hier beschrieben vorgehen:

https://wiki.unraid.net/Manual/Storage_Management#Backing_up_the_pool_to_the_array

 

Link zu den Manual's generell:

https://wiki.unraid.net/Manual

Hallo saber1,

mit dem Umstellen der shares auf cache=yes und mover starten habe ich begonnen. Ich kann da nur nicht erkennen, was da gerade passiert. Nach ca. 1,5 Tagen und Transfergeschwindigkeiten von ein paar kb habe ich den Vorgang beendet und den manuellen Befehl verwendet. Damit kann ich nun zumindest verfolgen, welche Datei gerade auf das Array geschoben wird. Der Vorgang dauert aber hier nun auch beinahe wieder zwei Tage...!?

Der Mover ist ausschließlich mit den Dateien unter /mnt/cache/system/docker/docker/btrfs/subvolumes/ beschäftigt. So viele Docker-Container habe ich nicht eingerichtet und mir bleibt die Frage, warum nun subvolumes auf das xfs-Array geschoben werden?

[DataCollector]

3 hours ago, DerTom said:

mit dem Umstellen der shares auf cache=yes und mover starten habe ich begonnen. Ich kann da nur nicht erkennen, was da gerade passiert. Nach ca. 1,5 Tagen und Transfergeschwindigkeiten von ein paar kb habe ich den Vorgang beendet

Da liegt irgendetwas im Argen.

Schreiben von Cache auf Array sollte doch schon im zweistelligen MB/s Bereich liegen (bei meinen 18TB Platten sind es bis zu 70MByte/s. Kleinere Festplatten sind ggf. langsamer).

Ist Dein Array oder die Cache SSD generell irgendwo zu langsam?

 

[DerTom]

38 minutes ago, DataCollector said:

Da liegt irgendetwas im Argen.

Schreiben von Cache auf Array sollte doch schon im zweistelligen MB/s Bereich liegen (bei meinen 18TB Platten sind es bis zu 70MByte/s. Kleinere Festplatten sind ggf. langsamer).

Ist Dein Array oder die Cache SSD generell irgendwo zu langsam?

 

Hallo DataCollector,

ich habe mir mal das Vergnügen gegönnt, den Dateitransfer etwas länger zu beobachten. Es scheint mir, dass zuerst die einzelnen Dateien in den subvolumes gelesen werden (dies ist der Vorgang, bei dem nur ein paar kb übertragen werden) und erst später der eigentliche Kopiervorgang (dann mit ca. 45 - 70 MB/s) erfolgt.

Das passt zwar grundsätzlich (Unraid soll ja bezüglich lesen optimiert sein und nicht hinsichtlich des Schreibvorgangs), ist aber doch verdammt langsam. In den letzten zwei Tagen wurden so ganze 3 GB übertragen, auf dem Cache-Laufwerk liegen noch 205 GB... 

 

[DataCollector]

17 minutes ago, DerTom said:

Das passt zwar grundsätzlich (Unraid soll ja bezüglich lesen optimiert sein und nicht hinsichtlich des Schreibvorgangs), ist aber doch verdammt langsam. In den letzten zwei Tagen wurden so ganze 3 GB übertragen, auf dem Cache-Laufwerk liegen noch 205 GB... 

Wie schon angedeutet. irgendetwas stimmt da nicht. 250GB sollten in 1-3 Stunden problemlos ins Array weggeschrieben sein.

[DerTom]

Tja, Umstellung habe ich vorgenommen, dafür fehlen jetzt diverse Dateien...

Da die letzten 200 GB durch den mover nicht bewegt wurden, habe ich diese direkt von der cache-disk auf das array geschrieben. Warum dabei 2TB an Daten auf das array gekommen sind ist mir nicht begreiflich - schließlich wurden auf dem cache-Laufwerk nur diese 0,2GB angezeigt. Die Dateien wurden nach 'system' kopiert, da es sich um docker-container handelte. Alle anderen shares waren als gesichert=grün markiert. 'ZFS-cache' Laufwerk erstellt und Array gestartet.

 

Docker-container neu erstellt und gestartet. Alte Konfiguration wurde geladen -> alles gut, dachte ich...

Die alten container (Ordner docker unter system) habe ich dann gelöscht.

Nun sehe ich, dass mir einzelne Dateien unter dem share der filme für meinen jellyfin-server fehlen, der aber als 'gesichert' unter der Registerkarte 'Shares' angezeigt wurde.

Mal ganz abgesehen davon, dass ich jetzt div. Filmchen verloren habe, welche anderen - weit wichtiger Dateien fehlen denn jetzt noch!?

 

Auch würde ich gerne verstehen, was da falsch gelaufen ist, um dies für die Zukunft auszuschließen.

 

Kennt jemand dieses verhalten?

[Ford Prefect]

23 minutes ago, DerTom said:

Kennt jemand dieses verhalten?

Das Daten dabei verloren gehen? nein.

Ich habe selbst nach der Standard-Vorgehensweise meinen Cache von BTRFS auf ZFS umgestellt.

Das "problem" mit dem langsamen mover für das Docker-Container (unter system) Verzeichnis hatte ich auch...abgebrochen und den Verzeichnisbaum zuerst dann gelöscht...da es BTRFS basiert ist und auf ZFS migriert werden soll, muss man die Docker eh neu laden, wenn Docker ein Verzeichnisbaum und keine vdisk ist.

Was man braucht/behalten muss ist das appdata Verzeichnis.

 

...bei mir hat das prima funktioniert....warum bei Dirr nicht kann man von hier nicht wirklich nachvollziehen.

Auch das Daten vom Array betroffen sind, soweit ich verstehe, ist mir schleierhaft. Bist Du sicher, dass Docker- und VM-Dienste gestoppt waren, ach als DU manuell, ohne mover verschoben hast?

Wie gesagt, für mich nicht zu rekonstruieren...

[DerTom]

13 hours ago, Ford Prefect said:

Das Daten dabei verloren gehen? nein.

Ich habe selbst nach der Standard-Vorgehensweise meinen Cache von BTRFS auf ZFS umgestellt.

Das "problem" mit dem langsamen mover für das Docker-Container (unter system) Verzeichnis hatte ich auch...abgebrochen und den Verzeichnisbaum zuerst dann gelöscht...da es BTRFS basiert ist und auf ZFS migriert werden soll, muss man die Docker eh neu laden, wenn Docker ein Verzeichnisbaum und keine vdisk ist.

Was man braucht/behalten muss ist das appdata Verzeichnis.

 

...bei mir hat das prima funktioniert....warum bei Dirr nicht kann man von hier nicht wirklich nachvollziehen.

Auch das Daten vom Array betroffen sind, soweit ich verstehe, ist mir schleierhaft. Bist Du sicher, dass Docker- und VM-Dienste gestoppt waren, ach als DU manuell, ohne mover verschoben hast?

Wie gesagt, für mich nicht zu rekonstruieren...

Hallo Ford Prefect,

die Docker-Container und die VMs waren beide deaktiviert.

Ich vermute einen Zusammenhang damit, dass 0,2 TB an Daten unter 'system' auf dem cache-drive nach dem kopieren auf das Array auf einmal über 2,0 TB belegten. Mit dem Löschen dieser Dateien - die ja unter system liegen sollten, die anderen shares waren alle vollständig gesichert (zumindest  nach der Anzeige) - werde ich wohl auch Dateien erwischt haben, die nicht nur unter 'system' lagen.

Warum kapiere ich nur nicht... Mist

[Ford Prefect]

5 minutes ago, DerTom said:

Ich vermute einen Zusammenhang damit, dass 0,2 TB an Daten unter 'system' auf dem cache-drive nach dem kopieren auf das Array auf einmal über 2,0 TB belegten.

...das ergäbe für mich nur Sinn, wenn Du in das system-Verzeichnis sebst weitere Dateien hineingeschoben hast. Die Blockgrössen der Dateissysteme sind nicht so unterschiedlich, dass so ein Delta zwischen Cache und Array herauskäme.

 

5 minutes ago, DerTom said:

Mit dem Löschen dieser Dateien - die ja unter system liegen sollten, die anderen shares waren alle vollständig gesichert (zumindest  nach der Anzeige) - werde ich wohl auch Dateien erwischt haben, die nicht nur unter 'system' lagen.

...weil - siehe oben - Du sie vielleicht vorher da reinkopiert/hinverschoben hast...mehr fällt mir auch nicht ein.

[saber1]

1 hour ago, DerTom said:

Docker-Container und die VMs waren beide deaktiviert.

Es geht um die Dienste:

Settings > Docker

Settings > VM-Manager

[DerTom]

3 hours ago, saber1 said:

Es geht um die Dienste:

Settings > Docker

Settings > VM-Manager

Ja,, beide Dienste waren disabled.

[nixweis]

Ich kann das Verhalten des Movers Bestätigen, bin wie "DerTom" genauso nach Anleitung vorgegangen, auch bei mir blieben ca. 200GB auf den SSDs zurück und liesen sich nicht übertragen, fast alle Docker waren "Leer" und 2 von 3 VMs waren "weg" die dritte VM wird hier bei direkt in einer Freigabe im Array gespeichert (Gott sei Dank, den  das war der PBS für die "Verschwundene" Proxmox VM).....

 

P.S. bei mir zeigte sich das Verhalten aber bei der Version 6.11.5, vor dem wechsel von SSD auf Nvme...

Edited April 30, 2023 by nixweis

[mgutt]

On 4/30/2023 at 9:21 AM, nixweis said:

fast alle Docker waren "Leer" und 2 von 3 VMs waren "weg" 

Was soll das heißen? Klingt eher nach kaputten docker.img und libvirt.img als realem Datenverlust von appdata oder Vdisks. Davon abgesehen bewegt der Mover Dateien. Er löscht nichts. Und es gibt das Mover Logging. Einfach einschalten und schauen was das Problem ist.

 

On 4/17/2023 at 9:30 AM, DerTom said:

find /mnt/cache/ -depth | /usr/local/sbin/move -d 1

Warum macht man sowas? Finger weg von der Konsole. Mover Logging und Mover starten. 

 

On 4/17/2023 at 9:30 AM, DerTom said:

Komisch ist m. E. auch, dass die Cache-nvme nur mit 208GB belegt, gleichzeitig aber meine Datendisk 1 nun um beinahe 1 TB zusätzlich belegt ist.

Klingt so als hättest du riesige Vdisks erstellt und da diese sparsig erstellt werden, haben sie auf der SSD nichts belegt, aber beim Verschieben verlieren sie nun diesen Zustand. Wobei ich meine, dass der mover sparse Dateien so belässt.

 

Was auch immer. Es gibt keinen Grund das docker Verzeichnis aufzuheben und zu verschieben. Einfach löschen und dann für den Rest den Mover anwerfen. Falls es lahm ist, auch mal den Reconstruct Write in den Disk Settings versuchsweise aktivieren. Ansonsten sag mal was du für HDDs hast.

[nixweis]

7 hours ago, mgutt said:

Was soll das heißen?

Wenn ich das wüsste, nur das die .img der betroffenen VMs weg waren, und alle Docker, die ich nach dem "Aktivieren" des Cache "Installiert" hatte, waren leer, inwieweit das mein Fehler war, weiß ich nicht, weil ich hier einfach die Standardeinstellungen des Cache + meine selbst erstellte Freigabe übernommen habe.

Aber für die nächsten Monate o. Jahre sollte mich das nicht mehr belasten, die erste Maschine hat jetzt 2TB Nvme Cache und die zweite Maschine 2,5TB Cache, keinen Grund da

jetzt weiter rumzuspielen 🙂

 

[Artur01]

Ich würde gerne auch meinen Cache nach ZFS umstellen. Spricht eigentlich was dagegen den Cache ins Array zu kopieren, dann nach zfs umformatieren und den Inhalt zurück kopieren? Docker und vm Dienst vorher deaktivieren.

[Ford Prefect]

2 hours ago, Artur01 said:

Spricht eigentlich was dagegen den Cache ins Array zu kopieren, dann nach zfs umformatieren und den Inhalt zurück kopieren? Docker und vm Dienst vorher deaktivieren.

Ja genau so wird es gemacht.

Allerdings für Docker brauchst Du nur das "appdata" Verzeichnis (oder was immer Du da konfiguriert hast um die Daten über Container-Starts hinweg zu sichern)

... die Docker images brauchst Du nicht (wenn als Verzeichnis abgelegt würde ich das vorher manuell löschen, sonst dauert das Verschieben ewig).

Nachteil dazu: wenn Du im Docker template "latest" definiert hast (was i.d.R. der standard ist), Du aber bewusst mal einen Docker nicht ge-updated hast weil Du die "latest" nicht haben wolltest / auf der lokal installierten Version bleien wolltest, wirst Du die latest dann nach der Aktion doch bekommen -> vorher die Version fixieren (Beispiel influxDB:1.8 ...latest ist 2.x oder gar 3.0 - wo sich auch intern was geändert hat und die Daten-Migration auch Probleme machen könnte). 

[Artur01]

So der Umzug auf ZFS hat funktioniert, Docker und VM laufen. Alle Dateien kopiert, also auch die docker Image Datei. Ich habe die Option "Compression" aktiviert und der Speicherverbrauch ist von 720GB auf 495GB (ca.30%) geschrumpft (Anzahl Files ist gleichgeblieben). Die Funktion scheint Sinnvoll zu sein da Cache bei den meisten eine SSD ist und diese von der Perfomance den anderen Gliedern (Netzwerk, Array) überlegen ist sodass hoffentlich in der Praxis nix zu spüren ist.

 

Edited May 4, 2023 by Artur01

[nixweis]

Gut... ich wollte das mal auf meinem Backup Unraid machen.

Im "Mover" liegen 236GB, Mover lässt sich nicht starten. wohl keine Dateien zum Kopieren vorhanden oder schon kopiert, jetzt VM und Docker unter den Einstellungen deaktiviert, und den Mover noch mal laufen lassen, ebenfalls keine Reaktion vom Mover.

Frage sollte ich bei allen Freigaben den Cache "deaktivieren" und den Mover noch mal Starten oder ist das Unnötig, was muss ich noch tun das mir derselbe Fehler wie oben nicht noch mal passiert (wäre beim Backup System kein Beinbruch), beim "Aktiven" System schon...

Edited May 9, 2023 by nixweis

[Ford Prefect]

5 minutes ago, nixweis said:

Frage sollte ich bei allen Freigaben den Cache "deaktivieren" und den Mover noch mal Starten oder ist das Unnötig,

Ich glaube Du hast da noch ein Verstädnisproblem.

Hier nochmal, was auch die Hilfe zum Cache in den Share-Einstellungen sagt - und genauso funktioniert es auch.:

Quote

Use cache pool (for new files/directories):

Specify whether new files and directories written on the share can be written onto the Cache disk/pool if present. This setting also affects mover behavior.

 

• No prohibits new files and subdirectories from being written onto the Cache disk/pool. Mover will take no action so any existing files for this share that are on the cache are left there.
• Yes indicates that all new files and subdirectories should be written to the Cache disk/pool, provided enough free space exists on the Cache disk/pool. If there is insufficient space on the Cache disk/pool, then new files and directories are created on the array. When the mover is invoked, files and subdirectories are transferred off the Cache disk/pool and onto the array.
• Only indicates that all new files and subdirectories must be written to the Cache disk/pool. If there is insufficient free space on the Cache disk/pool, create operations will fail with out of space status. Mover will take no action so any existing files for this share that are on the array are left there.
• Prefer indicates that all new files and subdirectories should be written to the Cache disk/pool, provided enough free space exists on the Cache disk/pool. If there is insufficient space on the Cache disk/pool, then new files and directories are created on the array. When the mover is invoked, files and subdirectories are transferred off the array and onto the Cache disk/pool.

NOTE: Mover will never move any files that are currently in use. This means if you want to move files associated with system services such as Docker or VMs then you need to disable these services while mover is running.

-> ergo, um mittels Mover Dateien vom Cache-Pool auf das Array zu verschieben, ist der Cache am Share nicht zu deaktiveren, sondern auf "Yes" zu stellen.

 

Bitte auch den jeweiligen, ausgewählten Cache-Pool beachten...nur der "default" Cache Pool heisst "Cache"...Du kannst in jedem Share einen beliebigen unraid -Pool als Cache-Pool verwenden.

[nixweis]

10 minutes ago, Ford Prefect said:

ist der Cache am Share nicht zu deaktiveren, sondern auf "Yes" zu stellen.

Genao so ist es 🙂
 

Dennoch habe ich mir die Freigaben einmal, jetzt unter der 6.12.0-rc5 genauer Angeschaut, ich kann den Cache ja gar nicht mehr Deaktivieren nur umstellen von "Cache = Array oder Array = Cache"
Ich glaube jetzt, nur für die Umstellung von "btrfs" zu "ZFS" gebe ich mir das nicht, der Cache... ähm der Primäre Speicher (SSD o. Nvme) wird durch die Umstellung auf ZFS auch nicht wirklich schneller, und die Datensicherheit habe ich ja durch die Parität im Array.

Edited May 9, 2023 by nixweis

[Ford Prefect]

19 minutes ago, nixweis said:

der Cache... ähm der Primäre Speicher (SSD o. Nvme) wird durch die Umstellung auf ZFS auch nicht wirklich schneller,

Ich habe den Wechsel vollzogen, weil ich mit BTRFS nur Ärger hatte....ZFS kenne ich schon lange und habe nur gute Erfahrungen gemacht....daher bin uch auf die 6.12rc gewechselt.

Ja, das Konzept wurde sprachlich umgestellt. Ob das nun verständlicher ist, muss man für sich selbst beurteilen...technisch aber ändert sich dadurch nix.

Bei mir wurde der NVMe- Cache-Pool um 2 Grad deutlich kühler mit ZFS...

19 minutes ago, nixweis said:

und die Datensicherheit habe ich ja durch die Parität im Array.

Äh, Du meinst Redundanz...was ist mit Redundanz im Cache-Pool/Primary Store selbst? Wenn da ein "Raid-Level", egal ob BTRFS oder ZFS gewählt wird, dass keine Redundanz hat, nutzt Dir die Parity nix.

[nixweis]

1 hour ago, Ford Prefect said:

was ist mit Redundanz im Cache-Pool/Primary Store selbst? Wenn da ein "Raid-Level", egal ob BTRFS oder ZFS gewählt wird, dass keine Redundanz hat, nutzt Dir die Parity nix.

Ja, das ist mir klar, aber die für mich "wichtigsten" Daten liegen im Array, die Daten die ich wie beim letzten Umstellen von SSD auf Nmve verloren hatte, waren schnell wiederhergestellt, nur sehe ich z. Zt. noch nicht so den nutzen (besser, ich bin z.Zt. einfach zu faul das dann neu einzurichten).
Und die Temperaturen sind auch nicht so kritisch die zwei Nvmes liegen bei 31° und die SSDs bei 28°C, alles recht entspand. 

[Ford Prefect]

4 minutes ago, nixweis said:

nur sehe ich z. Zt. noch nicht so den nutzen

Alles gut, ich will Dir das nicht einreden...gar nix falsch an Deiner Entscheidung.

Dachte nur, Du willst jetzt nochmal nachvollziehen, wie es "normalerweise" geht, nachdem der erste Versuch nicht der Bringer war...

[nixweis]

9 hours ago, Ford Prefect said:

Alles gut, ich will Dir das nicht einreden...gar nix falsch an Deiner Entscheidung.

Dachte nur, Du willst jetzt nochmal nachvollziehen, wie es "normalerweise" geht, nachdem der erste Versuch nicht der Bringer war...

Ja, das war mein Plan.... habe dann aber Überlegt das ich jetzt, so kurz vor unsrem Mittelalter Lager, keine Lust auf die Anpassungen habe.
Den mir passiert immer was bei so Sachen, aber ich komme gerne Nächste Woche auf dein Angebot zurück 🙂
Vieleicht finden man so den Fehler den ich die letzten beiden male gemacht habe, wobei die Anleitung der ich gefolgt bin nicht mehr auf die 6.12.0-rc5 eins zu eins übertragbar ist.