alturismo

check your appdata folder from jdown stop the container remove the core.jar and jdown....jar (or move them away as backup) restart the docker (files should be rebuilded) if the files are not rebuilded, may force an update on the docker. issue most common from an "unclean" shutdown (either docker itself or mashine) and resulting in corrupt files, known issue with ""java" dockers

nunja, solange dann nichts mehr auf dem array liegt wo darauf zugegriffen wird (regelmäßig) da ich da unter anderem Nextcloud sehe, das weckt gerne die Platte auf, vor allem wenn nicht entsprechend konfiguriert. isos (wenn mal VM kommt) domains (wenn mal VM kommt) scan, usw usw usw ... sind ja alle auf Array only konfiguriert, sprich, bei jeglicher Tätigkeit darin wird die ein oder andere oder mehrere Platten hochfahren, ist halt am Ende die Frage was und wie du willst, permanente Parity Protection, dann ja, Array (langsam und laut), Backup Strategie und mehr auf den cache verlagern, deine Entscheidung. bei 2 (unsinnigen) Shares (isos und vm) ist cache > array eingestellt, beim Rest nicht. vielleicht solltest du Ihn nochmals fragen oder dich etwas einlesen das du weißt was, wie, wo ... bedeutet, nur als Tipp.

ok, und gemäß den screens ein docker image, dann den einfachen Weg. 1/ Docker und VM Dienst aus (den Dienst, nicht nur die Dockers) 2/ Share Einstellung von /system, ändern auf primary cache, secondary array (array > cache) 3/ mover laufen lassen 4/ Kontrolle ob alles drüben ist 5/ Share umstellen auf primary cache, secondary none (cache only) 6/ Docker Dienst wieder starten, fertig. naja, steht ja da ;) im BIOS die entsprechende Funktion aktivieren, das wäre alles ;)

moin, am Ende wie du es bei appdata femacht hast. mit ein paar Anmerkungen 1/ nutzt du ein docker image oder docker verzeichnis ? (bitte screenshot hiervon) 2/ nutzt du vm's und ist der dienst aktiv ? (screenshot hiervon) 3/ und dein aktuelles Share setup zu /system (wahrscheinlich Array bei dir) 4/ und hast du noch etwas unter /system gemacht ? oder lässt du den Share "default" nur für docker und vm's.

nicht wirklich ;) USB abgeschafft, aspm gesetzt, powertop --auto-tune, mehr mache ich nicht System a System b Beide mit pico 160 W bestückt, beide mit ner 2.5G Karte bestückt (onboard aus) USB Devices hat hier halt geholfen, zigbee ausgelagert da auf einem rpi kvm wesentlich effizienter, usb boot auch mal deswegen getestet und hat auch nochmals was gebracht. CPU läuft immer im performance mode 32 aktive dockers auf dem ssd only system aktuell. aber auch hier springt die Power usage immer etwas

die Lösung hat @_alo_ beschrieben, daher wollte ich auch sehen wie den Share setup allgemein ist. du musst dir eigentlich nur deinen screenshot anschauen, es steht ja auch da was ... also, wie erwähnt wurde, docker stop, Share einmal umdrehen, mover starten, wenn alles erledigt ist, Share auf cache only stellen, Docker Service wieder starten, damit ist das "Problem" erstmal erledigt. Für deinen Umzug, Kurzfassung, Docker Service wieder stop Backup machen was auf dem cache liegt (einfach ins array damit) -- kann auch per mover gemacht werden, aber nutz den File Explorer und kopiere die Dateien da hin wo du die auch wieder findest. Hardware Umbau Unraid starten, cache neu zuweisen, formatieren. Jetzt kommen wir zu den nächsten Punkten, dein /system Share liegt auch auf dem Array, sprich, deine disk/s werden so nie in den spindown gehen ... wenn das ok ist, dann File Explorer, Backup wieder auf den Cache kopieren, Docker starten, fertig. Wenn System auch richtig gesetzt werden soll, melden ;)

Nein, Share Übersicht um zu sehen wie die konfiguriert sind

Ja, der entscheidende Teil fehlt 😉

mal davon ab dass das erstmal kein Fehler ist sondern eine Warnung hier fehlen noch ein paar Infos bevor man etwas rät, zeig mal bitte einen screenshot deiner Share Übersicht wo man auch appdata sieht, ebenso die Frage ob man das alles "auf einen Rutsch jetzt erledigen will inklusive disk we´´Wechsel. Normal wäre ein Weg um nicht viel kaputt machen zu können. 1/ Docker Service aus (Settings, Docker, OFF) 2/ VM Dienst aus (Settings, ... OF) 3/ Share/s umstellen (dazu den screenshot) 4/ mover laufen lassen das "aufgeräumt" wird aber erstmal bitte vorweg 1/ einen screenshot der Share Seite 2/ Prüfung deiner Dockers, hast du bereits irgendwo auf /mnt/cache/ etwas stehen oder steht alles sauber auf /mnt/user/ wenn bei 2/ irgendwo cache rauskommt, noch nichts machen da wir eventuell Dubletten vorliegen haben und das klären sollten.

das ist nicht wirklich viel ... zfs raid ist beispielsweise ein Preis den man zahlt naja, kommt drauf an was du machst Beispiel zweier n100 er Systeme beide mit einer 2.5G Karte bestückt, beide mit 160W pico psu, beide mit 32GB Ram ddr4 3200 ein System mit nur 2x sata SSD, ein System mit 1x nvme, 2x HDD (spindown 99%), System links, da laufen ~ 30 Dockers, sicherlich mehr Anwendungen wie du aktuell nutzt, abseits diverser plugins und scripts ;) vorher hatte ich noch ein Gaming VM Setup (performant), aber da nach meinem letztjährigen Umzug keine HDMI Verkabelung vernünftig umsetzbar war habe ich den entfernt (ist jetzt meiner Tochter Ihr Gaming Rig), hier dann "versteckt" im Wohnzimmer einen Gaming PC gesetzt welcher halt nur bei Bedarf Power braucht. Desktop PC ist auch zu Laptop/s mit Docking gewechselt und nur bei Bedarf ON. kurz, auch von mir, gehen stromsparende (Definition ... ?) Systeme im homelab, auf jeden Fall. mein Gaming und Desktop VM Setup (ink. 2 NV dGPU's, Wakü, 11 Lüfter, 2x nvme, 3x hdd, usw) war mit ~ 50 Watt im idle auch stromsparend ;) für das was es war ;) ist auch immer eine Frage der Definition.

ich sag einfach mal Nein, und Riser hat damit gar nichts zu tun. Beispiel, ich hatte in meinem VM Server jeweils eine GTX1060 und RTX3080ti verbaut GTX1060 ~ 6 Watt idle für sich RTX3080ti ~ 4 Watt idle für sich beides natürlich jeweils im persistent mode in Summe kostete es aber ~ 30 Watt anstelle 10 Watt nur weil die pcie slots belegt sind auf dem Board. Die Erfahrung habe ich durchgehend gemacht, daher auch diverse Tests ob man eine Karte "hot" swappen kann usw, war leider hier nie erfolgreich. Kurz, ein dGPU Setup verbraucht (leider) wahrscheinlich immer mehr als nur den Mehrwert der Karte an sich sondern noch zusätzlich Mainboard Saft.

hatte ich ja mal in einem anderen Thread bereits getestet (mit NV dGPU's) dass der Großteil rein von der Belegung des PCIe slots kommt, ich schätze hier ist das ähnlich, bringt nur nichts da wir nicht "hot" off / on schalten können (auch das hab ich versucht).

warum nicht ? und wenn deine Sammlung nur ripped wird ohne encoding braucht es auch keine GPU (die GTX braucht es dann nicht einmal).

alles gut 👍 bin ja kein "vibe" Gegner ;) wenn ich das für mich zusammenfasse, kleine web UI (das gefällt mir), Filter etwas granularer um "cache" Zeit individueller einstellen zu können (ok, kann man machen ... für mich jetzt weniger interessant), Plex Abfrage was geschaut wird und entsprechend N Folgen vorhalten anstelle komplette Staffel (ja, hatte ich mal überlegt und sogar mal implementiert, aber für mich sinnfrei da wenn ich ne Staffel starte, dann eh komplett geschaut wird). Hintergrund, ich hab es am Ende so schlank wie möglich halten wollen. Find ich aber cool was du da für dich passend umgesetzt hast, Top 👍 Hat mich nur interessiert, ich hab ja hier komplett umgebaut und auf dem Main Server gar keine HDD mehr, dafür einen 2. Server im sleep mit HDD's, ein vfs auf dem Main Server A wo das abbildet und nur bei Zugriff (Plex oder Emby) automatisiert 1/ Server B per wol weckt 2/ Copy von Server B > Server Main (cache mover) 3/ Server B wieder back to sleep damit hab ich halt den effizientesten Weg für mich persönlich gefunden.

das sollte von Haus aus gehen und der n100er schafft normal bequem 4-5 streams mit 1080p out. CPU Limit, kommt meist eher durch DTS-HD audio und co (cpu only transcode) schau mal im Host nach, Terminal ob low power enabled ist ich schätze fast du meinst mein plugin "cache-mover", was hast du denn da verbessert wenn ich fragen darf ? nur sofern es den betrifft.