_alo_

Stell dein docker lieber gleich auf macvlan um, um Problemen mit Fritz oder unifi aus dem Weg zu gehen. das Mover Tuning nutze ich nicht. das stellst Du im Share ein, wo neue Daten landen sollen (primary storage). die Ordner auf den Laufwerken (pool/array) werden dabei automatisch angelegt.

ah ja ok, ist dort auch beschrieben mit der Route zu dem Host. (advertising subnet routes)

im Tailnet gibt es diese IPs nicht

...waren meine zum Teil auch, aber Formatieren hat mir gereicht.

und du willst unbedingt preclear durchführen, weil?

ich auch nur einmal beim Hinzufügen einer Platte. Aber da er nach dem Preclear nochmal den parity check komplett durchgezogen hat (k.A. ob ich da was falsch gemacht hatte - eigentlich sollte er eine Platten mit ausschließlich 0en ja so hinzufügen können) und es so doppelt so lange dauerte, hab ich darauf im folgenden verzichtet.

Wo die Daten liegen kann man anhand der Einstellung nicht sagen, die besagt nur: wenn eine neue Datei in diesem Share geschrieben wird, landet sie zuerst im Pool "cache" und der Mover verschiebt sie später aufs array. Aber den Pool gibt es gar nicht, das ist schlecht... Ich bin mir recht sicher, dass sie so nicht direkt im Array landen. Aber ja, da war was 🤔: ich meine, wenn das so falsch konfiguriert ist, liegen neue Dateien glaube ich so lange in der Ramdisk und werden erst per Mover ins Array geschrieben??!? Würde bedeuten, dass Du heute Datenverlust hast, wenn neue Dateien noch nicht weggeschrieben sind bevor Du den Server runterfährst. Hattest du zu Anfang mal einen cache eingebaut? und das evtl. einfach nie geradergezogen? Weil Standard ist das eher nicht, dass Shares so angelegt werden, wenn kein "cache" vorhanden ist. Also ich würde das korrigieren und schauen, ob die Docker alle aktuell überhaupt noch sauber funktionieren und keine Date(ie)n fehlen. Also aktuell: primary=array Dann wenn dein neuer Pool funktioniert: primary=poolname, secondaray=array, mover action = array-->poolname Dann kannst Du schon alles starten und weiterarbeiten Der mover verschiebt dann beim nächsten Durchlauf alles auf den Pool und Du wirst den Geschwindigkeitsvorteil spüren. Du kannst den Mover auch manuell anstoßen, wenn Du es nicht abwarten kannst/willst ;)

prinzipiell alles richtig dafür gibt es Backups ;) nur zur Vollständigkeit: das beinhaltet nach dem folgenden Arraystart auch das Formatieren des neuen Pools mit ZFS Wenn das aktuell wirklich so konfiguriert ist: Hast Du aktuell doch schon einen "cache"? oder wo landen aktuell die neuen Dateien (primary storage)? Ich hatte es so verstanden, dass Du aktuell gar keine SSD hast und diese neu hinzufügen willst? Dann wären die shares aktuell so falsch konfiguriert, da es (noch) keinen "cache" gibt und alles auf dem Array liegt. Dann müsste es doch jetzt überall array-only sein, d.h. (primary=array, secondary=none, kein mover) richtig wenn dort /mnt/user/.... steht wäre das nichtmal zwingend notwendig, aber ja, ich würde das aus Performancegründen auch umstellen auf /mnt/poolname/... m.W. ja in den Pool-Settings gibt es den Punkt "Autotrim=on" (d.h. man kann es ausschalten, aber default=on) Move==Verschieben da sollten nach dem Mover Durchlauf keine Daten mehr vorhanden sein, sondern alles sollte verschoben sein (ruhig kontrollieren bevor Du alles wieder aktivierst) achte darauf die Shares bzgl. primary/secondary/mover richtig einzustellen (s.o.). Wenn Du dem neuen Pool einen anderen Namen als "cache" (=defaultname für ersten Pool) gibst, muss das natürlich auch so im Share / docker/VM-Pfad konfiguriert sein....

Kann theoretisch auch sein, dass der Provider den Port nutzt um deinen Router (über TR069 o.ä.) zu provisionieren und Du diesen Port eben nicht "überschreiben" darfst (bei den VPN Ports geht das ja schon, laut dem Hinweis). Wäre schon ein bisschen schräg, aber denkbar. Ich denke auch, dass Du Dich da mal an den Provider richten musst .... P.S.: Ist das die Webseite vom Router (was ist das für einer?) oder ein CSS des Providers, über den Du die Einstellungen Deines Routers bearbeiten kannst?

es läuft aber gerade auch nicht zufällig parallel ein Parity-check/-rebuild?

Für's Ausschließen von Hardware/Filesystem-Problemen wäre das System Log (bzw. Diagnostics) sicherlich hilfreich. Auf ein Parity geschütztes Array sollte das mit ca. 80MB/s und auf ein ungeschütztes mit ca. 200MB/s oder mehr schneller gehen. Das sind aber auch nur Maximalwerte. Dabei bleibt natürlich die Frage, was für Daten das waren oder ob der Server irgendwie anderweitig ausgelastet war? Das Übertragen einer großen 10G (Film-)Datei geht z.B. garantiert schneller, als das Übertragen von 10 Millionen 1 KB Dateien (z.B. Mailserver-Backup) 😉 Und wenn die CPU zu 100% mit was anderem beschäftigt ist, hat er zwischendurch nur wenig Ressourcen, Daten zu verschieben... Also etwas mehr Infos wären schon hilfreich ...

Naja, 80MB/s sollten da eher drin sein. Aber ich gehe davon aus, der Flaschenhals ist das NAS von dem kopiert wird. Was ist das denn für ein System?

Ja ist aktuell kein guter Kauf-Zeitpunkt für alles an Hardware was mit Speicher zu tun hat. Aktuell kann man eigentlich nur solche Angebote suchen und das Garantierisiko des shuckens eingehen: Ja klar, auf der Rückseite ist selten Platz für mehr, aber für sowas gibt es auch verschiedene Verlängerungskabel.

ja sorry, du hattest ja schon einen Screenshot mit den 7 kleinen HDDs gepostet 🤦‍♂️ hatte ich vergessen. d.h. Du hast aktuell 7 HDDs (hier würde ich mal überlegen auf weniger große zu wechseln, z.B. 2x 20TB, das spart auf jeden Fall Strom und das Problem des notwendigen ASM-Controllers - ist nur leider aktuell sauteuer🫣) ja natürlich Meine Idee war: einen ASM1166 im M.2 Format im rückseitigem M.2 Slot zu betreiben und gar keine NVMe zu nutzen, sondern auf SATA-SSDs zu setzen. dann hast Du 4x SATA onboard + ASM-Controller = 10 SATA-Ports. Also drei frei für SATA-SSDs ;) Dann kannst Du den vorderen M.2 und den X16 Slot freilassen.

ob C2 oder C3 jetzt so einen Unterschied machen, glaub ich nicht. Wie viel SATA brauchst du denn? Wäre das weglassen der NVMe und stattdessen ein M.2-ASM1166 mit 1-2 großen SATA-SSDs + 4-5 HDDs vielleicht auch eine Option?

kommt mir bekannt vor 😉 ich bin von Synology + NUC für docker gewechselt auf ein Node304 mit einem Featuritis-ITX-Chinaboard und dann schnell gemerkt, dass das nicht das wahre ist. ja eben, ein Raid0/1 aus ungleich großen Platten wird nicht funktionieren, aber ich war verwundert, dass die beiden NVMes direkt untereinander stehen. Meine 3 Pools werden getrennter dargestellt (vielleicht liegt das an der unraid Version? ich bin auf dem System noch bei 6.12.15):

in dem du im Main-Tab bei unassigned Devices ein SMB share hinzufügst über "ADD REMOTE SMB/NFS SHARE" - ich hab hier mal eins als Beispiel hinzugfügt dieses kannst du dann später nach Bedarf (un)mounten

Für volle (gaming) Performance sind der GPU-Slot und der erste M.2 i.d.R. immer (kenne kein anderes consumerboard) an die CPU angebunden und das wirst Du auch nicht ändern können. Wovon das dann abhängt, ob das Pkg dann durch die Benutzung dieser Lanes wachgehalten wird oder nicht, weiß ich nicht 🤷‍♂️ Ich kenne jedenfalls niemanden, der diese Lanes nutzt und noch C10 erreicht. Data kam bei seinem Board durch das reine Einbauen einer NVMe immer noch auf C6. Viele Systeme gehen bei Nutzung der Lanes aber nur noch bis C2. Muss man testen. Der Vorteil von (m)ATX Boards ist eben, dass überhaupt/mehr Platz für Chipsatz-angebundene Devices/Slots vorhanden ist. So konnte ich auf meinem ATX-Board mit z690 Chipsatz z.B. neben 8x SATA noch 5x NVMe + 10G Karte nutzen ohne die CPU-angebundenen Lanes zu belegen - so erreiche ich auch C10. P.S.: wie hast Du überhaupt deinen Cache aufgebaut? (cache 500GB + cachetwo 1TB, beide XFS, unterschiedlich stark befüllt)??

wenn mit dem "vorderen" M.2 Slots einen meinst, der an die CPU-angebunden ist, kann die Benutzung die Ursache sein, jedenfalls war es bei meiner 10G Karte im CPU-angebundenen X16 Slot ebenfalls der Falls: statt C10 nur noch C2.

ja, weil der PC die Daten erst zu sich kopiert und dann auf das Zielsystem, die Daten gehen also zweimal durch's Netz. Das ist vielleicht die für Anfänger naheliegendste und einfachste Lösung, aber von der Geschwindigkeit und dem Stromverbrauch (da ein System mehr laufen muss) wirklich die schlechteste Methode. Besser direkt kopieren! Einfach ist immer relativ, je nach Vorkenntnissen... Sicher im Bezug auf was? Ich bevorzuge rsync auf der Konsole (auf die WebGui würde ich hierfür verzichten), das kannst Du z.B. auch jederzeit abbrechen und neu starten. Info: falls du die Web-Konsole aufrufst und dort Befehle absetzt, die länger laufen, werden die mit Schließen des Fensters gekillt. Also entweder wissen, wie man die in den Hintergrund schiebt und ggf. später wieder nach vorne holt, oder lieber gleich die Lokale Konsole am Server nutzen. wie ich es machen würde: auf deinem NAS SSH aktivieren beim unraid Server auf der lokalen Konsole einloggen per Rsync Befehl die Daten vom NAS auf unraid rübersynchronisieren z.B. mit diesem Befehl: "rsync -avz --progress --times --recursive [root/admin-user]@[NAS-IP]:[Quell-Pfad auf dem NAS] /mnt/user/[emby-Ziel-VZ]" (die eckigen Klammern zeigen dir nur, was Du ersetzen solltest, die nicht mit eingeben! zu den Optionen kannst du Dich ja einlesen) Alternativ kannst du die NAS-Freigaben auch per unassigned Devices mounten und dann innerhalb von unraid vom einen in den anderen Ordner kopieren, hast dann aber SMB dazwischen.

Sowas hatte ich befürchtet, deswegen hatte ich das angemerkt. Zum Vergleich belegen meine 25 docker Container inkl. appdata ca 300gb und das ist schon viel (da muss ich nochmal schauen woran das liegt). Bei mir ist dieser Pool 1TB groß und daher liegen auch hier Shares drauf… der Rest liegt auf den anderen beiden Pools

Genau, darin liegen normalerweise die Systemdaten von docker und VM. Man kann natürlich auch alle Standards umstellen, wenn man weiß, was und warum man das tut ;) eine etwas seltsame Formulierung - du meinst Du hast einen extra Pool für all Deine Shares als Schreibcache?! Der mover verschiebt je Share nach Konfiguration die Daten zwischen primary und secondary-storage. Die entsprechend konfigurierten Shares können (als primary Storage) dabei aber auch auf jedem Pool liegen, auch auf deinem "ssd". Auch können Shares ohne secondary Storage (also die der mover überspringt) überall liegen: auf deinem NVMe-Pool, dem SSD-Pool oder dem Array. (strenggenommen kann man auch primary=array und secondary=pool einstellen, aber das macht nun mal gar keinen Sinn) Ich hab schon verstanden dass Du Shares&docker (warum auch immer?) strikt trennen willst, aber ja nach Größe Deiner redundanten SSDs verschenkst Du so ggf. recht viel Platz, wenn Du nicht extrem viele/große Docker Container betreiben willst....oder reden wir hier von extrem kleinen alten SSDs?

den Satz verstehe ich nicht Vielfach empfohlen ist das BN341 (PurePower 12M), das 13M ist der Nachfolger und laut Datas Tests minimal schlechter, hat aber leider auch weniger Anschlüsse für Laufwerkskabel... Das BN341 sollte ATX3.1 sein, dieses BN502 scheint das etwas ältere PP12M mit ATX3.0 zu sein?!

viel, ja, aber anscheinend hast Du ja schon einen BLocker laufen, wozu das jetzt noch im Plex-Container selbst umleiten? Das bringt Dir doch nicht wirklich was?!

Sleep Modes sollten im Bios konfiguriert sein - da mal geschaut? Evtl. geht er wirklich in einen deep sleep (z.B. Suspend to RAM) und wacht nur noch per kurzzeitigem Druck über die Powertaste wieder auf? Das macht für einen Office-PC vielleicht Sinn aber nicht für einen Server....schau mal, ob Du entsprechende Parameter im Bios findest. Kann ich mir kaum vorstellen, aber es wäre sicher einfacher, testweise ein älteres Bios zu flashen als die CPU auszutauschen...