_alo_

Ist es vielleicht ein reservierter Begriff in Unraid, der eben auch in den GUI-Übersetzungen zu finden ist? Was passiert denn, wenn man Shares nach anderen internen Begriffen z.B. aus dem Menu benennt, wie "shares", "tools", "settings", "plugins", "apps",...?

Ein Hauptgrund ist neben Bequemlichkeit und abfangen der Peaks eben auch der Stromverbrauch. Wenn für jede Mini Datei immer zwei hdds (Daten+parity) anspringen und für 15min (default spindown) laufen und dabei ja 5W ziehen kann das über den Tag schon viel werden. Der Verbrauch der ssd ist dagegen kaum messbar. Mein Backup Server läuft ohne parity. Wenn das skript läuft zeigt rsync nahezu volle Bandbreite an (meist über 200MB/s bei 2,5Gb LAN mit Flow Control), k.a. Warum das bei dir so langsam ist.

Verstehe ich nicht. Ich dachte du hast das raid aufgelöst und Docker / Daten aufgeteilt auf die beiden nvmes…. Jetzt willst du sie wieder zusammenfassen zu einem raid? Hast du denn vorher alles kopiert und ist die zweite auch leer?

noch eine weitere Aktualisierung ich habe wieder zurückgesteckt (ca. 10:58) und die Cyberpower muss anscheinend auch wieder nachladen. Umstecken wie gesagt ca. 1min, danach lädt (anders kann ich mir den Mehrverbrauch nicht erklären) die USV über 20min nach: die ersten ca. 10min lag sie bei >40W, danach etwas niedriger bei ca. 35W und jetzt liegt sie wieder bei ca. 25W. die Eaton dagegen: wird vielleicht auch etwas weniger, aber längst nicht so stark.

so, ich habe die beiden USVn umgesteckt: aus Steckdose --> Shelly PlugS (gelb) --> VP700ELCD --> Shelly PlugS (blau) --> BackupServer Steckdose --> Tasmota Nous A1T (grün) --> 3P700UD --> Fritz!Dect200 (rot) --> MasterServer wurde Steckdose --> Tasmota Nous A1T (grün) --> VP700ELCD --> Shelly PlugS (blau) --> BackupServer Steckdose --> Shelly PlugS (gelb) --> 3P700UD --> Fritz!Dect200 (rot) --> MasterServer also die Beschriftung in HA hab ich nicht angepasst(!), nur umgesteckt: das Umstecken hat aufgrund der beengten Platzverhältnisse locker eine Minute gedauert, d.h. die beiden USVn müssen sicherlich erst wieder etwas nachladen..... die cyberpower (jetzt grün) ist schon wieder runtergegangen: die Eaton (jetzt gelb) verbraucht auch so einiges mehr als der Server daran (rot) also mein Fazit: die cyberpower verursacht weniger Mehrverbrauch als die Eaton ;) P.S.: Ich weiß natürlich nicht, was die Fritz!Dect so im Vergleich zum Shelly PlugS ausmacht oder ob der unterschiedliche Verbrauch der Server hier viel ausmacht im Verbrauch der beiden USVn. Aber auf den Aufwand alles komplett durchzutauschen (USVn und Strommesser) verzichte ich mal.... wobei man echt sagen muss, die Aktualisierungen der verschiedenen Steckdosen ist schon merkwürdig: das ist jetzt die Eaton (shelly) vor dem großen Server (FritzDect). Der Server-Verbrauch geht hoch, der von der USV nicht? Teilweise verbraucht die USV weniger als der Server daran? also ja, keine wissenschaftliche Messung (hier ist auch nichts geeicht!), aber der Trend ist glaube ich erkennbar. Ich behalten trotzdem beide 😉

wie zuvor geschrieben hab ich jetzt die Cyberpower: Steckdose --> Shelly PlugS (gelb) --> VP700ELCD --> Shelly PlugS (blau) --> BackupServer und zusätzlich hab ich ja noch die Eaton am anderen Server: Steckdose --> Tasmota Nous A1T (grün) --> 3P700UD --> Fritz!Dect200 (rot) --> MasterServer Hier also mal als direkter Vergleich die Eaton: man sieht auf jeden Fall, dass die Tasmota recht träge auf Stromschwankungen reagiert und noch weniger Details als die Fritz Dose zeigt. Aber es sind fast durchgehend mehr als die 6-8W+ (jedenfalls in der Anzeige) Hier mal alle zusammen: als nächstes steck ich mal um, um zu sehen, was der shellyPlugS anzeigt vor der Eaton... Edit: die Eaton scheint sich etwas zu beruhigen, sie ist teilweise nur noch 3-5W drüber:

Ich hab dagegen eher aufgerüstet: 4K Beamer, 2,90m breite AT-Leinwand, 7.1.4 Setup mit DBA aus 8x 12" Subwoofern, Vorstufe, diversen Endstufen und DSP....der nächste Step werden vollaktive Lautsprecher. Neben sehen und hören kann man den Film hier auch entsprechend fühlen bei Referenzpegel 😁 Sorry, genug OT

Ah ok, kann internal boot nicht von einem RAID-Konstrukt booten? Wusste ich auch nicht.... Aber ich sehe da auch keinen Vorteil vom internal Boot. Klar, bei manchen gehen die USB-Sticks irgendwann kaputt oder sie sind langsam und das Booten dauert 5min (echt, so lange?) Ich nutze 4€ SanDisk mini Sticks seit drei Jahren und hatte noch keinen Ausfall. Ich habe aufgrund der USV-Thematik heute beide Server mindestens einmal gebootet (meine Fehler 🤪) und mit den 1-2min kann ich gut leben....Dank USV könnte es gut sein, dass die Server jetzt ewig laufen bis was kaputt geht. Wozu booten? im XML-Dateinamen steht der Namen deines Docker-Containers (also zwischen "my-" und ".xml") im Reiter docker siehst du alle installierten docker Container unter /mnt/user/system/docker/unraid-autostart steht die Liste, welche automatisch gestartet werden, das sind die, wo der Autostart-Haken (im docker-Tab) gesetzt ist:

Ich bin kein Freund von Transcoding und streame mit voller Qualität, da ist es m.M.n. egal, ob jellyfin das macht oder SMB. Wo genau siehst du da den Unterschied? Ich kenne die Internas von Jellyfin da nicht genug. Meine Sammlung 720p, 1080p und 2160p in optimaler Qualität (UHD, Atmos etc.) umfasst bei der Anzahl auch nur 40TB.... (die Mediatheken-Downloads zähle ich hier nicht zu) Ich sammle auch erst seit 20 Jahren (=erster DVD-Kauf) und lade außer von Mediatheken nichts aus dem Netz. Ich nutze Kodi auf dem HTPC mit dem MPC-HC als externen Player in Verbindung mit MadVR (für DTM und upscaling) und da kann ich definitiv kein Transcoding zu schlechteres Qualität im Vorfeld gebrauchen, daher: direct-play

Ok, das hatte ich vermutet, obwohl das bei mir nicht großartig negativ auffällt. Bei mir läuft Jellyfin und entweder greife ich direkt mit entsprechenden Clients zu, oder per Kodi mit Jellyfin-AddOn. Bei einer vierstelligen Anzahl an Medien und kurzem Scrollen dauert es bei mir keine 10s bis nacheinander 4-5 Platten angelaufen sind und keine Platzhalter mehr zu sehen sind, also kein großer Unterschied als ob alle gleichzeitig anlaufen.

OT: Wozu genau nochmal eine Spinup-Gruppe mit dem kompletten Array?

danke fürs Erinnern 😉 Ich habe jetzt folgendes Setup: Steckdose --> ShellyPlugS (gelbe) --> VP700ELCD --> Shelly PlugS (blau) --> BackupServer Wie zu sehen schwankt der Verbrauch bei beiden Shellys unabhängig konstant, aber man kann schon sagen, dass der Verbrauch der VP700ELCD nicht wirklich höher ist, als ohne Last (der zweite Shelly macht natürlich auch was aus). Ich sag mal ca. 3W Mehrverbrauch durch die USV ist realistisch. Ich hatte vorher die Eaton per USB angeschlossen, jetzt nur umgesteckt und nichts umkonfiguriert, sie wurde direkt erkannt:

Noch eine Randbemerkung von mir: es wäre übrigens besser für diese Community, wenn du deine Posts (auch wenn es nur Deine Unwissenheit war), nicht einfach löscht, oder wieso finde ich den "(dringend)...." Post zu der Aufteilung deiner Cache-SSDs nicht mehr? Anderen, die ähnliche Probleme haben, könnte die Erkenntnis doch auch helfen... zum Thema: Was hast du denn jetzt genau gemacht? das war ein Raid1, welches Du aufgelöst hast. richtig? Warum eigentlich? hast Du denn danach die neue "Daten"-Platte gelöscht/formatiert? Wenn die 1TB leer wären, kann ich mir gerade nicht erklären, wieso da nicht <1TB draufpassen sollten mit deinem rsync-Befehl.... Von wann ist der Screenshot? vor/nach dem Versuch? hier liegen ca. 750GB auf dem Cache und 500GB auf Daten. Natürlich passen die 750GB nicht zusätzlich zu 500GB auf eine 1TB Platte... --> Vielleicht schaust Du Dir erstmal an, was alles so auf den beiden Laufwerken noch für Ordner existieren und wie viel Platz noch frei ist bzw. ob das passt, was du vor hast. @alturismo schrieb ja schon, dass /mnt/cache/appdata (bzw. /mnt/user/appdata) DER wichtige Ordner mit deinen persistenten docker-Daten ist, den Du kopieren willst ich hole mal etwas weiter aus... In den Einstellungen des Docker Dienstes sind die Pfade konfiguriert: Die Daten zu den docker-Apps liegen wie der Default-Name es vermuten lässt unter Appdata. Unraid fasst mit dem Fuse-System alle Laufwerke unter /mnt/user zusammen, d.h. mit dieser Pfadangabe /mnt/user/appdata ist es egal, ob Dein Ordner auf /mnt/cache/appdata oder /mnt/Daten/appdata liegt (oder teils/teils), die Summe der Daten ist immer erreichbar unter /mnt/user/appdata. (doof ist nur, wenn die gleiche Datei auf mehreren Laufwerken zu finden ist, aber das sei ein anderes Thema) Du brauchst hier also nichts ändern, wenn Du ihn verschiebst. Im System-Ordner liegen die docker images (in einer großen Image-Daten oder im Directory-Modus) die aus dem repository entsprechend der docker Konfig runtergeladen werden. Diese sind quasi "unwichtig", heißt, Du kannst die jederzeit löschen und neu runterladen, was ja z.B. auch beim Update eines docker-Containers gemacht wird. Dieses System Verzeichnis brauchst Du also für deine docker nicht unbedingt verschieben oder sichern. Du kannst Deine laufenden Docker-Container jederzeit wiederherstellen mit dem Konfigtemplate und den persistenten App-Daten. Was Du dafür brauchst, sind die Konfigurationstemplates (quasi "die docker-Edit-Seite" in der GUI): Hierin ist für den jeweiligen docker-container u.a. eingestellt, wo seine persistenten Userdaten liegen sollen: i.d.R. ein Ordner /mnt/user/appdata/[dockername] DAS sind daher die wichtigen Daten die Du kopieren solltest (und von denen Du auch backups haben solltest! das Plugin "Appdata Backup" kann ich hier empfehlen) Wenn in deinen docker-Konfigs überall /mnt/user/appdata/... steht, kannst Du das auch alles so lassen, da unraid über das fuse-Dateisystem ja alle Laufwerke unter /mnt/user zusammenfasst, d.h. es ist an dieser Stelle für den docker-container egal, ob appdata nun auf /mnt/cache oder /mnt/Daten liegt. Das erwähne ich nur, weil, falls du hier einen docker hast, der das fuse Dateisystem umgeht (kann sinnvoll sein) und /mnt/cache/appdata/... konfiguriert sein sollte, findet er seine Daten nicht mehr, wenn du diese auf /mnt/Daten/appdata verschoben hast ;) D.h. also in der Regel kannst Du einfach docker-Dienst stoppen, den Ordner appdata von /mnt/cache nach /mnt/Daten verschieben, und könntest jetzt den docker-Dienst wieder starten und alles würde danach wieder laufen. ABER: Du solltest Dir vorher noch das Share anschauen/anpassen: (iirc ist das die default-Einstellung des Shares "appdata") Hier ist konfiguriert, auf welchem Laufwerk neue Dateien/Ordner gespeichert werden! Wenn Du den docker-Dienst einfach nach verschieben des appdata-Ordners wieder startest, hast du zwar alle deine alten Daten auf /mnt/Daten/appdata/... aber wenn Du eine persistente Änderung in einem docker machst, landet diese Datei wieder auf /mnt/cache/appdata/.../..., also solltet Du hier vor dem Start des Dienstes auch den Zielort für neue Dateien anpassen auf "Daten" damit auch zukünftig alles an einem Ort bleibt!! Mit dem System-Share ist es ähnlich. Du kannst den Share einfach anpassen, dass neue Dateien auf "Daten" geschrieben werden. Wenn Du jetzt den docker-Dienst stoppst und /mnt/cache/system z.B. umbenennt in /mnt/cache/system-alt (oder ihn löscht/verlierst), findet unraid ihn nicht mehr und er wird beim starten des Dienstes das docker-image/Directory unter /mnt/Daten/system neu erstellt und danach sind leider erstmal alle deine docker-container weg! Du kannst sie dann neu hinzufügen, da deine Konfigurationstemplates (User-Templates) ja noch da sind mit den Pfadangaben etc (s.o.) Wenn Du hier ein Template deiner docker-Container auswählst, lädt er daraus alle Einstellungen in die GUI und wenn Du unten apply drückst, lädt er das docker Image neu aus dem konfigurierten repository und startet den Container mit diesen Einstellungen. Daher macht es keinen Sinn, den System Ordner zu sichern/kopieren/verschieben.... So kannst Du den Pool für die beiden docker-relevanten Shares appdata und system ändern. Aufwendig, aber machbar, wenn man versteht wie unraid funktioniert mit dem Fusesystem und dem primary/secondary storage in den Shares. Basis Shell-Kommandos wie cp, mv, rsync, mkdir, rm, rmdir, ... sind hierbei natürlich auch hilfreich, da der Weg über die GUI oft ultralangsam ist... P.S.: wenn es Dir nur darum gehen sollte die System Shares von dem Schreibcache zu trennen auf zwei einzelne NVMEs, wäre es vielleicht auch einfacher (bzgl. der Dienste docker/VM und allem obigen), die System-Shares (system, appdata, domains, isos) so zu lassen wie sie sind und Deine übrigen shares anzupassen, so das primary-storage statt auf "cache" auf "Daten" zeigt (secondary sollte ja "Array" sein) und somit dieses neue Laufwerk als Schreibcache genutzt wird. (Wie die Pools heißen spielt ja überhaupt keine Rolle, "cache" ist nun mal historisch bedingt der default-Name für den ersten Pool - mehr nicht) Nur als Denkanstoß... Also am besten möglichst genau beschreiben was Du warum vorhast (und was Du ggf. schon gemacht hast)

So wenig Stromverbrauch bei nur C2 ist ungewöhnlich, aber gut wenns für dich passt. 👍

Noch ist sie allerdings im Leerlauf, dh es hängt nichts(!) dran, nichtmal usb. Einfach nur Strom in Steckdose (Shelly plugs).