_alo_

dann schau mal, ob deine Container noch richtig funktionieren.... Wenn ein docker-container z.B. eine wichtige Datei neu geschrieben hat und du jetzt den Ordner gelöscht hast, könnte der Container ggf. nicht mehr laufen oder komisches Verhalten zeigen... bei appdata gilt das gleiche: - wie sind primär/sekundär und die mover-action eingestellt? - wo existiert der appdata Ordner überall und wo sind die Dateien verstreut? Eigentlich sagt die Meldung im den Fix Tool ja auch nur aus, dass Du das nicht ideal konfiguriert hast und die Performance der Applikationen leidet, weil der Ordner Appdata auf dem langsamen Array liegt...

ja, üblicherweise moved der mover auch keine docker/VMs daher gibt es da nachts dann auch kein Problem P.S.: das Plugin appdata-backup stoppt die Container, erstellt ein Backup und startet sie dann wieder das macht der mover offenbar nicht, aber wie gesagt, das kommt ja auch quasi nie vor!

wenn der Mover etwas verschieben soll, dann folgender Tipp: system wieder auf primär=array stellen --> dann ist alles wieder da, prima! System sekundär auf cache stellen mover-action auf Cache<--Array stellen Dienste stoppen Mover starten (auf main-tab, brauchst nicht über Nacht warten) dann sollten die system-Daten alle auf dem Cache liegen primär/senkundär tauschen (damit neue Dateien auf primär=cache landen) dienste starten Bei deinem appdata ist durch das einfache Umstellen des Primärspeichers offenbar das Problem entstanden, dass alte auf dem array und neue auf dem Cache liegen. Das kriegst du über die Share Einstellungen so nicht gelöst, sondern müsstest die Daten manuell verschieben (das Plugin unbalanced kann das iirc nicht, oder?)

ich dachte, dass hätten wir oben schon geklärt? der mover moved nur zwischen Primär und Sekundär Speicher und zwar so wie die Mover-action eingestellt ist!! Du kannst nicht einfach primär (für neue Dateien!!!) umstellen und erwarten, dass etwas von den alten Daten verschoben wird

Nein, hast Du nicht Damit der Mover laufen kann, dürfen die Dateien nicht im Zugriff sein, d.h. Du musst dafür den docker-&VM-Service deaktivieren (settings-docker-enable docker=no und genauso für VM)! dann den Mover laufen lassen dann kontrollieren, ob alles richtig verschoben wurde dannn die shares anpassen (wenn du willst) dann die Services wieder aktivieren 2. hast Du wohl ausgelassen, oder auch schon 1. ?

Poste mal die Ausgabe von diesem in der Konsole eingegebenen Befehl: lspci -vv | awk '/ASPM/{print $0}' RS= | grep --color -P '(^[a-z0-9:.]+|ASPM )' und die relevanten BIOS-Einstellungen zum Thema ASPM, die Du vorgenommen hast. Dann solltest Du Dir powertop 2.15 installieren und dort die Ausgabe der Pkg C-States und der tuneables (vor/nach "powertop --auto-tune") ebenfalls hier posten. "HA als VM verbraucht mehr als als docker" die Aussage kenne ich auch, allerdings ist der Mehrverbrauch meiner HA-VM ggü. anderen docker Containern fast nicht messbar (im Bereich 0,x W). Du hast auf jeden Fall primär andere Themen

ja, eigentlich schon. Ich vermute, dass auf dem array noch der Ordner "system" existiert (ohne Inhalt) und er das deshalb so anzeigt...

bitte nicht in den Quote hineinschreiben sondern drunter Du beziehst Dich in Deiner Antwort auf die Leseraten, richtig? Dass hier bei unraid-üblichen Cache-->Array Shares die Daten fast immer vom Array (also von einer HDD) gelesen werden, sollte klar sein, da sehe ich auch wenig Nutzen von 10GE. Beim Schreiben jedoch schon. Ich plane z.B. einen 4TB Pool, in dem ich "arbeiten" also lesen/schreiben möchte, bis ich die Daten am Ende manuell auf's Array schiebe. Da sehe ich auch einen Nutzen. Was der TE allerdings mit 10GE und so einem kleinen Cache für Docker und als Schreibcache vorhat, ist noch nicht klar...

Schau vielleicht mal in meinen Thread: Das z690 PG Riptide ist ein ATX-Board, das wirst du nicht in ein ITX Gehäuse bekommen Da musst Du schon zu einem großen ATX-Gehäuse greifen, wie dem Define/Meshify/... oder einem Jonsbo N5. Ich habe auf der zweiten Seite meines Threads ein Foto vom Board im Meshify2 hinter einem Node304 gepostet, da siehst du was ich meine. Mit "10G-over-Ethernet" meinst du vermutlich 10G-Ethernet über eine elektrische RJ45-Verbindung statt eines SFP-Ports (optisch/DAC)? Bei der Frage RJ45 oder SFP+ kommt es in erster Linie auf die Gegenstelle an: was kann Dein Switch oder nutzt Du z.B. wie ich lediglich eine ptp Verbindung. Ich nutze eine AQC113C-RJ45 Karte und erreiche mit ASPM weiterhin C10. Der idle-Mehrverbrauch dieser Karte mit aktivem 10GE Link beträgt am Server lediglich 2,57 W. Es geht hier weniger um die Frage, ob eine bestimmte Maximalleistung ausreicht (ich persönlich denke 400W sollten bei dir reichen, wahrscheinlich sogar noch weniger), sondern ob das Netzteil in der Minimallast (was ja auch dein Ziel ist) sehr effizient ist. Da sticht das von dir ausgewählte BN341 offenbar heraus, weswegen es hier halt auch so oft empfohlen wird... Bei 64GB RAM würde ich statt 4x 16GB lieber auf 2x 32GB gehen für zukünftige Erweiterbarkeit. Bei der QVL bist Du sicherlich auf der sichersten Seite, aber die Hersteller testen ja auch nie alle Module (wie auch?), von daher würde ich nach funktionierenden Builds Ausschau halten (z.B. meinem oder bei PCpartpicker.com) um weitere Modelle zu ermitteln, die günstig/lieferbar sind. Ich nutze z.B. Mushkin Essentials, keine Ahnung ob die auf der QVL stehen...

🤦‍♂️ja, hab ich von früher auch noch installiert.... danke für den Hinweis. zu der Frage nach der Dauer gibt es auch die History: Unter Settings - Scheduler sind die Einstellungen zu finden, er hat dann nachts u.a. aufgrund von folgendem pausiert:

der Screenshot hätte etwas mehr zeigen sollen

Ich hatte gestern einen Stromausfall und der Server begann nach Neustart um 10:30 Uhr dann mit dem Parity-Check. Soweit so gut. Wir hatten ja letztens das Thema wie lange das so dauert und mir fiel gerade erneut auf, dass das bei unraid (6.12.15) etwas seltsam angezeigt wird: Warum ist das so? Wie gesagt, er läuft seit gestern 10:30 Uhr. Hat er nachts pausiert (wann? warum?) und läuft erst seit 03:48 Uhr wieder? Wenn er in 29 Min fertig ist, wie lange hat er dann in Summe gelaufen? 🤔 Ich hätte jetzt gesagt: 10:30 - 00:00 = 13,5h 00:00 - 10:15 = 10,25h Summe = 23,75 Stunden oder gab es eine Pause? Leider habe ich seit ein paar Tagen sporadische Probleme mit dem DECT Empfang meiner Fritz-Steckdose, daher kann ich nicht 100%ig sagen, dass die Platten durchliefen, aber ich gehe fest davon aus (war die letzten Male auf jeden Fall so und da war mir die Anzeige auch schon so aufgefallen):

also für docker und jellyfin würde ich generell einen cache empfehlen, eine (oder redundante) ssd. Wenn Dir ohne parity eine HDD ausfällt, startet dein array nicht mehr, weil die dann defekte HDD fehlt. Dann baust du eine neue ein, weist die dem Slot zu und startest das Array. Dein Backup mountest Du dann ein, z.B. über unassigned Devices (USB, SMB, etc. wo Dein Backup halt liegt), und kopierst dann die Daten manuell auf die neu hinzugefügte leere HDD.

Der Vorteil einer Parität bei unraid (oder einem entsprechenden RAID bei anderen Systemen) ist in erster Linie die ununterbrochene Datenverfügbarkeit bei einer oder zwei ausgefallenen HDDs. Das Wiederherstellen und generell der Paritätscheck dauern zwar lange, aber währenddessen sind die Daten eben verfügbar! Alternativ wären die Daten weg bis das Restoren aus dem Backup durch ist. Kann sein bzw ist wahrscheinlich, dass das Restoren aus dem Backup schneller geht als das Wiederherstellen aus der Parity, aber dafür hast Du eben die Übergangszeit, in der die Daten nicht verfügbar sind 🤷‍♂️ Wie wichtig Dir das ist, musst Du selber wissen... P.S.: der Paritycheck dauert auch bei größeren Platten in aktuelleren Systemen ca. 1,5 Tage. Will sagen: bei meinen 18TB Platten dauert das ggü. deinen 4 TB jetzt nicht mehr als viermal so lange, sondern auch nur etwas über einen Tag, nur zur Info

die Integration verursacht die vielen SSH Logs, die macht m.W. kein php

ich nutze es, hier meine Main-Einstellungen: und ja, es erzeugt ZIP Dateien, auch vom Stick, wenn man möchte: pro Ordner dann alle einzelnen Zip Dateien: Ich denke, das wird das quasi gleiche Archiv sein, was man auch unraid connect runterladen kann, nachdem man dorthin mit internen tools seine Config hochlädt... es ist ein Abbild des kompletten Sticks, außer dem Ordner previous.

👍 ich bin zwar auch ehemaliger Synology-User, aber auf die Idee, ein NAS virtuell als Maschine auf/in einem NAS laufen zu lassen, bin ich noch nicht gekommen. Interessehalber: wozu machst du das? 11TB is ja nicht gerade wenig...

also läuft bei Dir nur dieser eine docker-container mit dem virtuellen DSM? Dieser schreibt (über die Angabe "Disk location") in den Share domains, dieser liegt im Array. da ich diesen Container nicht kenne: kann es sein, dass dieser die "disc" als eine große Datei schreibt? Wenn dem so wäre, kann unraid diese ja auch nicht über das ganze Array aufteilen, sondern sie liegt dann nur auf der einen Platte. Vielleicht postest Du mal den Inhalt des Shares domains?

Jein. Du musst auf jeden Fall erstmal den User wechseln ("su $USER") und als dieser dann in den/die entsprechenden Ordner wechseln um die Apps auszuwählen, die Du nachts prefillen möchtest. Du könntest die Befehle schon hintereinanderschreiben, wenn Du immer alles durchgehen willst, z.B. cd ${DATA_DIR}; cd EpicPrefill; ./EpicPrefill select-apps; cd ../SteamPrefill; ./SteamPrefill select-apps; cd ../BattleNetPrefill; ./BattleNetPrefill select-apps Dann werden die einzelnen Auswahlen direkt hintereinander geöffnet. Den Befehl kannst Du Dir auch in ein shellskript schreiben, aber bringt Dir das viel? Also ich kaufe relativ selten neue Spiele, die ich prefillen möchte und erst recht nicht in allen Stores. Ich ändere hier eher nur selten was und dann nur an einzelnen Stores....da reicht mir die Anleitung und die wenigen Steps dafür... Edit: Du meinst, das per Skript von außen zu starten, also inkl. Login in die lancache-prefill-Docker-Konsole? ja, das geht bestimmt auch, hab ich noch nicht gemacht, aber ich sehe hier den Vorteil auch wie gesagt nicht....

Ja klar sind die Log Einträge (und die Funktionalitäten der Integration) nicht mehr da, wenn die Integration nicht mehr läuft , aber die macht keinen wirklichen größeren Stromverbrauch. Die Abfragen laufen ja den ganzen Tag im bestimmten Interval. Wie gesagt, man kann die aus Gründen der Übersichtlichkeit in ein extra Log auslagern, aber hier geht es ja um Deinen Stromverbrauch über die paar Stunden.

Das wird vermutlich die unraid-HA-Integration sein, die läuft bei mir auch und ermittelt die Werte per SSH (da es ja bei unraid noch keine geeignete API gibt...). Es gibt aber auch ein Howto, diese SSH Logs aus dem System Log herauszutrennen... Mir waren im Log auch noch Einträge zu einer DS415 aufgefallen: macht die (oder was anderes) zufällig nachts ein Backup auf dein unraid?

Unter "Tools" gibt es den Punkt "new Config": Hiermit kannst Du mit einer neuen disk-Konfiguration starten und deine bestehenden Platten zuweisen. Daten gehen erst verloren, wenn Du irgendeine Platte formatierst. Es sollte hier nur um die Informationen gehen, aus welchen disks dein array/cache/pool aufgebaut ist. Du kannst hier auch bestimmte Zuordnungen behalten:

Wie unraid das nachträgliche hinzufügen handelt, weiß ich leider auch nicht, ich bin direkt mit einem redundanten Pool gestartet Er "verteilt die Daten dann nicht wie benötigt", sondern sie werden softwareseitig gespiegelt. d.h. nachher haben beide NVMe-SSDs (meinst Du die mit "FP"??) die gleichen Daten, so dass jederzeit eine der beiden ausfallen darf. Aber Ein Backup der Daten (docker/VM stoppen, Daten kopieren) kann nie schaden!! Oder gleich so wie oben teilweise beschrieben durchführen: Shares auf Cache --> Array stellen dienste docker/vm stoppen mover ausführen Cache sollte danach leer sein, Daten sollten auf Array liegen (man könnte die Dienste jetzt wieder starten, aber sie wären halt langsam und die Array Platten bleiben im spinup) zweite SSD einbauen, Pool redundant aufbauen Shares auf Cache <-- Array umstellen mover wieder laufen lassen Shares sollten dann wieder auf dem Cache landen Dienste starten

Die Daten liegen bei unraid immer an nur einem Ort: auf dem Cache ODER auf dem Array. Wenn man schon einen SSD-Cache hat, will man i.d.R. die Docker Container/Daten auch da liegen haben für schnellere Zugriffszeiten und vor allem um Strom zu sparen, da die Stromfressenden HDDs aus dem Array sich dann schlafen legen können. Daher ist der Standard hier auch Cache <-- Array Also ja: wenn Dein Cache aus nur einer SSD besteht und diese kaputt geht, sind die Daten darauf natürlich nicht mehr vorhanden und die Docker Container können nicht mehr laufen, dazu braucht es auch keinen Neustart... Wenn deine single Windows SSD kaputt geht, stürzt die Kiste auch ab und es ist Ende.... Dann sollte der Mover die Daten auch verschieben (aber warum? siehe oben), aber das geht wiederum nur, wenn sie nicht im Zugriff sind, also sollte der docker-Dienst dafür besser gestoppt sein. Wie gesagt, macht m.E. wenig Sinn. Lieber den Cache redundant bauen und/oder sowas wie "Appdata Backup" verwenden: das Plugin stoppt die Container nachts kurz, sichert den Ordner appdata auf's array und startet die Container wieder. Wenn Dir dann die SSD kaputtgeht, hast Du ein Backup der Containerdaten, was nicht allzu alt ist.... Wenn man keine Redundanz im Cache hat, sollte man Ausfallrisiko gegen Backuphäufigkeit abwägen... Das Update sollte damit nichts zu tun haben, oder ich hab Dein "Problem" noch nicht richtig verstanden

Ob einen eleganten/besseren Weg gibt, weiß ich nicht, dazu am besten in der Doku mal suchen. Ich würde in diesem Falle die Daten manuell verschieben von /mnt/disk_x/share_z zu /mnt/disk_y/share_z