Torben

That's also my plan, the Pi4 with OpenWRT is already prepared. The sad thing about this is that it was working flawlessly with 6.8.3 and something somewhere somehow broke the functionality starting with 6.9. But well, because of that I started looking at OpenWRT and got something new to tinker with.

Me too. And even NFS speed over wireguard got worth running at about 60% of the speed it was before. So I tried to find a workaround and installed an Ubuntu VM with the folders mounted via mount-tags on the receiving unRAID server, which I found out causes the problem (even a fresh installed test server on different hardware on 6.8.3 works, same server on 6.9+ shows the problem). So far it's working great for a couple of weeks now. In the beginning I wanted to do some more investigating on why it works in the VM - or if I can replicate the problem in the VM -, since I think having a VM just for doing what the host was/should be capable of is "a bit" unnecessary, but well, a lot of time spent and no real idea left where to continue. I'm curious what happens when you have new hardware.

Ich habe das Ganze jetzt nochmal auf dem Testserver mit 6.10.0-rc1 probiert und das Problem tritt auch dort auf. Durch das Begrenzen der Geschwindigkeit per --bwlimit kann man es verzögern, aber im Endeffekt ist es das gleiche Resultat.

Die beiden neuen Videos (6.8.3 und 6.9.2) sind nun auch da. Den Verschlucker in der 6.8.3 habe ich in der Timeline markiert. 6.8.3: https://youtu.be/UBZm8w79oKw 6.9.2: https://youtu.be/yDiTijYkVSA

Hups, Hälfte vergessen. Ich synce beim Testen eine große Datei, rsync holt über SMB ab. Wobei ich auch schicken als Workaround probiert hatte, wo es nur länger dauerte, aber auch zum Problem führte. Hier habe ich aber nicht getestet, ob es mit 6.8.3 funktioniert. Rsync-Parameter: -av --human-readable --progress

Korrekt, keinen Cache. Ich missbrauche meinen "Gaming Computer" als Test-Server und konnte nur eine nVme freischaufeln. Geschwindigkeit ist eigentlich auch wurscht, da der Durchsatz per iNet kommt. 🙂 Ach ja, das Wireguard-Plugin habe ich natürlich auch installiert. Verbindung ist "Remote access to server" und die MTU habe ich auf 1280 runtergesetzt. Wobei es bei 6.8.3 als Receiver auch mit "Auto" geht (das ist ja 1500-80), aber da ich das bei jeder Verbindung so habe, eben auch hier. Ansonsten keine Veränderungen.

Das hatte ich schon mal (mit großen Bauchschmerzen) auf meinem Haupt-Server probiert und war froh, dass das Hin- und Herspringen problemlos funktionierte. Der Transfer allerdings funktionierte nicht sauber, sprich wie bei 6.9.2. Ich kann das aber gerne nochmal auf dem Test-Server durchführen. Ansonsten geht mir die ganze Zeit durch den Kopf, dass beide Server Intel I219V onboard NICs nutzen und hier vielleicht ein Treiberproblem vorliegen könnte? Nur eine Vermutung, basierend auf "Das hat was mit der Netzwerkverbindung zu tun". 🙂

Der Sender (mein Haupt-Server) ist ein 6.9.2er unRAID mit verschlüsseltem Array und Cache. Nur der Vollständigkeit halber erwähnt, ich glaube derzeit nicht, dass der Sender relevant ist. Der Receiver (mein Test-Server) hat keinerlei Verschlüsselung oder ähnliches, nur eine nVme als Array-Disk. Verschlüsselung etc. habe ich extra weggelassen, um zu schauen, ab welchem Schritt das Problem auftritt. unRAID 6.9.2 installiert, Community-Apps installiert, Nerd Tools installiert (für Tmux, iotop etc.) und mittlerweile auch Unassigned Devices inkl. Plus installiert (da das Problem auch ohne auftritt). PS: Auf dem Test-Server kann ich anstellen was ich will, wenn es den zerlegt mach ich ihn neu. Der hat keinen anderen Auftrag, als das Problem zu analysieren. 🙂

Soderle, ich habe nun eine weitere Testrunde gefahren und den Test-Server (Receiver) auf 6.8.3 downgegradet (/boot/bz*-Dateien mit denen aus dem 6.8.3-DL überschrieben...hatte das Vorgehen im unRAID-Forum gefunden). Und siehe da, es funktioniert wieder - zumindest ohne den Kollaps. Zwar vereinzelt mit Einbrüchen wie sie bei 6.9+ auftreten, allerdings fängt sich das Ganze innerhalb von ein paar Ticks wieder...daher ist uns das vorher auch nicht aufgefallen (das gute alte "Fire and forget"-Problem 🙂). Die CPU-Last ist ein wenig höher, bei der Download-Geschwindigkeit komme ich auf 200+ MBit anstatt 450+ MBit, aber das kann auch an meiner INet-Verbindung zuhause liegen, die ist heute zickig. Daher hatte ich das Ganze auch nochmal direkt hintereinander mit 9.2 durchgeführt und hatte die gleichen Probleme wie vorher. Die Videos werde ich sichten und auch hochladen, das dauert aber noch ein wenig. Vorab: Wäre es möglich einzelne Komponenten von unRAID zu aktualisieren, um den Auslöser weiter eingrenzen zu können (ich würde die Change-Logs durchgehen)? Sprich z.B. ein Update von Samba durchzuführen, den Rest aber zu lassen wie er ist? Oder würde das, selbst wenn es geht, wenig Sinn machen, weil alles ineinander verwoben ist?

Erst einmal Entschuldigung für die lange nicht erfolgte Rückmeldung. Irgendwo ist irgendwas schief gelaufen und ich konnte mein Windows nicht mehr booten (nein, ich habe nicht die falsche nVme gemountet 🙂 ). Wurscht, nu ist alles neu und gut. Da mir nach der Wiederaktivierung des Write Caches aufgefallen ist, dass mein Geschreibsel oben ...Blödsinn?... ist, habe ich nun ein paar Videos mit htop (Shift-K), top, iotop und unRAID-Dashboard (CPU + Network) gemacht, um das Problem zu zeigen. Vielleicht kann ja jemand etwas daraus ablesen oder mir einen Tipp geben, was ich analytisch noch machen könnte. Der für mich einzige Anhaltspunkt, was die 100% Core-Last im "Fehlerfall" erzeugt, ist der Netdata-Docker, der zu dieser Zeit 99%+ iowait auf dem entsprechenden Core anzeigt. Vielleicht könnte man darin sehen was es erzeugt, aber bei der Masse an Daten bin ich im Moment bisschen überfordert. Leider hatten sich meine Videoschnitt-Programme dazu entschieden aus meinen zusammengeschnittenen Aufnahmen unlesbaren Brei zu machen, daher gibt es eine Youtube-Playlist (sollte das nicht erlaubt sein, bitte löschen oder bescheid geben):

Das hat sich doch schon wieder gelohnt. Ich habe top immer nur genutzt, weil man halt alle Prozesse sehen kann...ja, nee, mal googlen wie das in htop geht war zu schwer. Auch die Info bez. des Dashboard-Loads ist Gold wert, jetzt kann ich 2 Kopfschmerztabletten weniger nehmen, weil die angezeigte Last nun endlich Sinn macht. 😄 Ich habe die beiden Dinge kombiniert und da es ein Test-Server ist (warum bin ich darauf nicht früher gekommen...), habe ich die Dirtypages gleich mal auf 0 gesetzt. Begonnen habe ich mit XFS für den Cache (Array ist immer XFS) und dachte mir, dass das Mounten der externen Verbindung auf dem Array vielleicht Sinn macht, wenn ich auf den Cache schreibe. 1. Auf /mnt/disk1/dir (USB HDD) gemountet und /mnt/cache/dir1 (nVme) geschrieben: Ca. 50-120 MBit - 2 rsync-Prozesse, die in Summe ~96% IO ergeben (es schreibt aber immer nur einer, wechseln sich ab), ab und zu nur 1 Prozess mit 96% IO (der andere hat 0%), wechselt aber wieder auf 2 Prozesse. Die CPU-Last (i9-9900K) ist recht hoch, alle Cores springen wild herum, aber das Problem tritt nicht auf. 2. Auf /mnt/cache/dir gemountet und /mnt/cache/dir1 geschrieben: Ca. 50-190 MBit - starkeres Springen der Geschwindigkeit (vermutlich durch Lese-/Schreibvorgänge, die ja nicht mehr durch den RAM glattgebügelt werden), Rest ist gleich, das Problem tritt nicht auf. Dann kam BRTFS für den Cache. 1. Auf /mnt/disk1/dir gemountet und /mnt/cache/dir1 geschrieben: Geschwindigkeit 14-22 MBit - Es werden wieder 2 rsync-Prozesse gespawnt, aber Prozess 1 zeigt sich dominant, erzeugt dauerhaft 96-99% IO, Prozess 2 wird gespawnt, tut gem. iotop gar nichts und danach nur sehr, sehr sporadisch etwas, gem. htop zeigt er minimale (aber stetige) CPU-Last. Das Dashboard zeigt über mehrere Sekunden Last auf einem Core von 100%, die dann auf einen anderen Core überspringt und dort einige Sekunden verweilt, bevor es weiter geht. Während ich das hier geschrieben habe ist die Geschwindigkeit auf 4 MBit gefallen, das Dashboard zeigt weiterhin 100% wechselnd auf einem Core (htop "nichts"). In iotop ist es allerdings ruhig (alles ~0%), bis - passend zum Core-Wechsel im Dashboard - beide rsync-Prozesse gleichzeitig nach oben springen...Prozess 1 mit 99,99%, Prozess 2 mit 17-61% und nach der nächsten Aktualisierung von iotop ist ggf. Prozess 2 noch mit 5-20% da, je nachdem wie hoch seine IO vorher war. 2. Auf /mnt/cache/dir gemountet und /mnt/cache/dir1 geschrieben: Gleiches Bild wie bei BTRFS 1. 3. Auf /mnt/cache/dir gemountet und /mnt/disk1/dir geschrieben: 15-40 MBit - 2 rsync-Prozesse, Prozess 1 mit 96-99,99% IO dominant und daueraktiv, Prozess 2 verpieselt sich auch gleich und tritt auch hier sehr, sehr sporadisch in Erscheinung. Der Unterschied zum Schreiben auf /mnt/cache ist, dass ein Core im Dashboard zwar immer noch deutlich stärker belastet wird (65-100%), aber er bleibt nicht bei 100% hängen und der Wechsel der Cores passiert auch mit einer deutlich höheren Frequenz. Das Problem, dass das Ganze "hängen" bleibt und die IO auf 0% absinkt und die beiden rsync-Prozesse zeitgleich IO erzeugen (und die Geschwindigkeit einstellig abfällt), tritt hier nicht auf. Prozess 1 bleibt dauerhaft mit 96-99,99% aktiv. 4. Auf /mnt/disk1/dir1 gemountet und /mnt/disk/dir geschrieben: Gleiches Bild wie bei BTRFS 3. Da ich jetzt so richtig hart verwirrt war, dass egal wie bei BTRFS formatiertem Cache nur 1 rsync-Prozess IO-aktiv war, habe ich vorsichtshalber den Cache nochmal als XFS formatiert und es waren wieder 2 rsync-Prozesse IO-aktiv, wie oben beschrieben. Das macht mich alles fertig, ich hoffe Du kannst daraus irgendwas sinnvolles stricken. Da ich diese und nächste Woche Urlaub habe, kann ich gerne noch ausgiebig testen, Analyse-Tools installieren, was immer...aber gedanklich bin ich grad raus - das ist für mich zu tief in Linux/Dateisystemen etc. und unlogisch des Todes (weil ich halt mangels Wissen/Ideen nicht den Schimmer habe warum es auftritt). Vielleicht schaffe ich noch was zu ergooglen, wenn ich wieder weiß auf welchem Planeten ich gerade bin. Aber vielen, vielen Dank schon mal für Deine Hilfe...dass es mit BTRFS zu tun haben könnte, da wäre ich im Leben nicht drauf gekommen.

So, ich habe nun noch ein bisschen mit meinem eigenen Server weiter getestet. Ich bin zwar fast genau so schlau wie vorher, aber...ja, vielleicht hat ja jemand eine Idee, was ich probieren könnte. Zur Überprüfung habe ich mit Windows per Wireguard-Client von meinem unRAID-Server gezogen: Ganz normal mit dem Explorer auf das Share (per /mnt/user/share und /mnt/diskX) zugegriffen und mit 530-550 MBit geladen. Das wurde vermutlich durch meine Leitung zuhause gebremst, da ich "nur" 50 MBit Upload habe und der Rückkanal 51-55 MBit verbrauchte (Holy Shit). Beim unRAID-Server keine Auffälligkeiten, keine Last-Spitzen, nur dauerhaft 3-4% zusätzliche CPU-Last durch Wireguard-Verschlüsselung etc.pp. Dann habe ich mir einen unRAID-Stick fertig gemacht, in den vorherigen Windows-Rechner gesteckt, "Community Apps" installiert, Wireguard installiert, gleiche Tunnel-Konfig wie zuvor verwendet, manuell gemountet (ganz billig einfach nur mount -t cifs -o) und getestet. Vorab: Um das Problem zu "resetten" reicht es zu unmounten, 3-5 Min zu warten, wieder zu mounten und das Spiel kann von vorne beginnen. Mountet man vorher schraubt sich der Transfer im Kilobit-Bereich hoch bis auf irgendwann mal 10 MBit. In allen Fällen lese/schreibe ich direkt über /mnt/cache bzw. /mnt/diskX. Temp-Server zieht vom Haupt-Server: Anfangs 530-600 MBit, Rückkanal 4-20 MBit (ich habe nur per GUI geschaut). unRAID-Oberfläche des ziehenden Temp-Servers zeigt direkt Auslastung eines Cores mit 90-100% an (springt weiter auf andere Cores, in htop und top sieht man das komischer Weise nicht), in iotop kloppen sich der "Midnight Commander" und "[unraidd1]" mit 99%+ um den ersten Platz. Bis der 100%-Core plötzlich nicht mehr so schnell wechselt (unRAID-GUI), in iotop nur noch alle paar Sekunden 99% für MC angezeigt werden und die Geschwindigkeit auf 10 MBit fällt. htop und top zeigen immer noch keine nennenswerte CPU-/Core-Last an. Haupt-Server schiebt auf den Temp-Server: Von der Idee her gleiches Bild, dauert nur länger. Die Cores auf dem empfangenden Temp-Server schaukeln sich in der unRAID-GUI hoch, wenn oft genug hintereinander 100% da steht fällt die Geschwindigkeit auf 10 MBit. Haupt-Server zieht vom Temp-Server: Das Gleiche wie andersrum, nur mit leitungsbedingt geringeren Übertragungswerten. 🙂 Ich installiere gerade interessehalber eine Windows-VM auf dem Haupt-unRAID-Server und will mal schauen was passiert, wenn ich darin mit dem Wireguard-Client ziehe. 🤯

Sorry, das hätte ich gleich dazu schreiben können, ich umgehe bei meinen Netzwerktests immer SHFS, um das als Faktor auszuschließen. 🙂Ich nutze /mnt/cache und habe in diesem Fall sogar mit /mnt/diskX gearbeitet, da ich etwas von möglichen BTRFS-Problemen gelesen hatte, die sich aber nicht bestätigten (2x verschlüsselte Samsung 870 SSD im RAID 1). CPU ist ein Intel i9-10900T. Wenn ich von /mnt/diskX auf /mnt/cache kopiere ist alles gut und geht mit voller HDD-Lese-Geschwindigkeit ohne erwähnenswerte IOwaits. MBit, geht per INet, daher auch Wireguard. Wie gesagt, SMB lokal konnte ich leider noch nicht testen, da ich eine sehr lang Zeit nach Problemen bei Wireguard gesucht hatte, bis ich auf iotop gestoßen bin und mir damit endlich die CPU-Belastung erklären konnte.

Hallo zusammen, ich bastel seit Wochen an einem Problem herum, das ich einfach nicht gelöst bzw. ordentlich analysiert bekomme. Daher wende ich mich an Euch, da mir einfach die Ideen und die Google Suchbegriffe ausgegangen sind. Ich möchte gar nicht all zu sehr auf das eingehen, das ich bisher probiert habe (reicht gefühlt bis "Mit Weihrauch um den Server tanzen"). Wichtigster Punkt ist, dass ich die MTU für die Wireguard-Verbindung mittlerweile auf 1280 gestellt habe, was für Glasfaser-Verbindungen wohl empfohlen wird (Paketfragmentierung tritt bei Ping nicht auf, auch bei höheren MTUs nicht). Der Rest waren wildeste Überlegungen und Gestocher im Unbekannten. Zusatzinfo: Ich nutze das Unassigned Devices Plugin für das Mounten der Shares. Ich bin der Meinung ich habe auch ohne getestet, wenn jemand sagt: "Mach ohne", teste ich das aber gerne auch nochmal. Nun aber zum Problem: Der Dateitransfer per Wireguard + SMB/NFS erzeugt massiv IOWAIT (wie ich mittlerweile herausgefunden habe), wenn unRAID "zieht". Wenn ich die gleiche Datei über die gleiche Verbindung in das gleiche Verzeichnis schiebe ist die CPU-Last völlig normal, kein IOwait, nichts. Das Ganze äußert sich so, dass im Endeffekt 1 (HT-)Core auf 100% Last hoch geht (gem. iotop 99,8% IOwait durch rsync/MC) und diese 100% dann von einem auf einen anderen Core umspringen. Die Verbindungsgeschwindigkeit geht von 250-270 MBit/s auf 10-12 MBit/s runter. Wenn ich die Übertragungsgeschwindigkeit begrenze (runter bis auf 50%) dauert es länger, schaukelt sich aber über die Zeit hoch und das Endergebnis ist das gleiche. Sobald die Geschwindigkeit gefallen ist erzeugen rsync/MC 99,8% IOwait, dann wieder nicht, dann wieder, dann wieder nicht usw. Bisher war es so, dass die Geschwindigkeit bei NFS auf 100 MBit/s stabil lief, seit Kurzem (ich denke seit einem Update von Unassigned Devices) fällt aber auch diese nach einer gewissen Zeit auf 10 MBit/s. Zusätzlich möchte ich erwähnen, dass ein Speedtest (self hosted per Librespeed) in diesem "Fallback"-Zustand über die WG-Verbindung mit maximaler Leitungsgeschwindigkeit läuft, was ich als "Die WG-Verbindung funktioniert" deute. Ich habe das Ganze auch mit der neuen 6.10rc1 (auf dem Receiver) getestet, dort stellt es sich per SMB grundsätzlich gleich dar, nur dass der hängende Core nicht mehr überzuspringen scheint (oder zumindest deutlichst verzögert, ich habe nach 1 Min abgebrochen). Per NFS konnte ich gar nicht ziehen. Ich bin für jede Frage/Vermutung/Idee dankbar mit der ich das Problem weiter eingrenzen kann, denn ich bin mit meinem Latein am Ende. PS: Ich bin mittlerweile der Meinung, dass WG nicht das Problem ist. Da mein Server aber nicht mehr bei mir steht, konnte ich leider noch nicht testen, ob das Problem grundsätzlich bei SMB-Transfer auftritt. Vielleicht kennt ja jemand dieses Problem, der lokal per SMB arbeitet oder kann es nachstellen.

Perfekt, abermals Dank. Dann baue ich das mal nach und schaue was passiert.

Alles klar, danke schon mal für die Infos, eine Frage bleibt dennoch: 🙂 Original Plex.inc oder Original Limetech (in Templates gesprochen)?

Meine Gedanke der automatischen Überwachung war, dass Plex mitschneidet WAS verändert wurde und den Rest in Ruhe lässt. Dass die ausschließlich nach dem Modify-Datum des Ordners gehen (vermutlich um CPU zu sparen), einen Library-Scan lostreten UND anscheinend noch einen "Schau vorsichtshalber nochmal nach, ob sich hier nicht auch was geändert hat, wenn er aufgerufen wird"-Flag auf die anderen Filme setzen, damit hatte ich nicht gerechnet...war wieder Bernd am Start. Bisher ist es mir auch nie aufgefallen, vermutlich durch das Folder Caching. Wobei das komisch ist, dass bei Dir die Platten dauerhaft schlafen. Das FC-Plugin hatte ich damals nur wegen Plex rausgesucht, weil er beim Library-Scan eigentlich auch immer nachschauen sollte, ob die Mediendateien denn noch alle existieren. Welchen Docker nutzt Du? Ist jeder Film in seinem eigenen Unterordner? Hast Du das gesamte Share eingebunden oder gehst Du auf die Ordner auf den Platten (war noch eine Idee meinerseits)? Nutzt Du die Plex Pass Beta-Version oder die Stable? Ich versuche nur auszuschließen, dass es an was anderem als Plex liegt, bevor ich im Plex-Forum schreibe: "Einzelordner helfen nicht so richtig."

Hallo mal wieder, ich nutze den Plex Docker von Linuxserver.io und das Folder Caching-Plugin. Derzeit beobachten ein paar Freunde und ich, dass Platten "unnötig" (also ohne den Film zu starten) hochgefahren werden, z.B. wenn man nur das Cover anklickt, um die Zusammenfassung/Extras des Films anzusehen (/appdata/ liegt natürlich auf dem SSD-Cache). Per Browser sehe ich, dass das Dashboard-Icon oben rechts anfängt sich mit "Aktualisiere Metadaten" zu drehen, bei 50% stoppt und nachdem die Platte an ist, dann instant fertig ist. Beim TV-Client ist es so, dass das ganze Bild zum Drehkreis wird bis die Platte an ist. Wir sind der Meinung, dass das erst seit ein paar Updates der Fall ist. Also habe ich im Plex-Forum gepostet und ein Plex-Mitarbeiter meinte, dass das daher kommt, dass alle Filme in einem Verzeichnis liegen. Sobald sich der Modifiziert-Zeitstempel des Ordners ändert, ist das wohl "schon immer" das Signal für Plex, dass sich "irgendwas" in dem Ordner geändert hat. So weit, so gut, der neue Film wird ja auch hinzugefügt. Dass nun aber auch bei allen anderen Filmen die Medien-Platten starten und Metadaten aktualisiert werden (lokale Daten sind deaktiviert wo man sie deaktivieren kann), ist mir neu...oder ich habe es verdrängt. Ich habe dann ein Test-Share angelegt, in dem die Filme in separaten Ordnern liegen und dort ist es immerhin schon mal besser und die Platten werden nicht bei jedem Film gestartet. Hat einer von Euch dieses Verhalten auch als "neu" beobachtet oder sagt Ihr: "Das war bei mir schon immer so." Zweiteres hieße dann, dass irgendwas mit dem Folder Caching nicht mehr hinhaut. Wobei die Logs des Folder Caching durchaus korrekt erscheinende Daten aufzeigen.

Hatte ich auch gedacht, nachdem ich mehrere Stunden meinen vermeintlichen Konfigurationsfehler gesucht hatte. Ist meiner Meinung nach in Plex hart verdrahtet bei Nutzung des "Fernzugriff", man kann nur den Port der Website ändern (was auch immer einem das bringen soll). Wobei ich nicht mal sicher bin, ob ich das Ganze über plex.tv probiert hatte, vielleicht schleust er es dann komplett über den angegebenen Port? Wie auch immer...ich nenne sowas bei Plex gerne: "Das hat Bernd vor 10 Jahren programmiert, wir wissen nicht was es tut und hängen nur Code dran." Die Datenbank ist dafür auch ein gutes Beispiel...sieht eigentlich logisch aus, bis man was ändert und gaaaanz komische Dinge passieren. Das ist cool. Wollte ich auch probieren, als an meinem verwandtschaftlichen Server-Standort FTTH gelegt wurde...aber dann lief mir die Zeit davon und ich habe halt doch wieder 'ne IPv4 beantragt (für 5 Euro/Monat, ich dachte ich lese nicht richtig). Irgendwann setze ich mich in "urlaubiger Ruhe" nochmal dran, vielleicht ist Dein Guide ja dann schon draußen. 🙂

Auch wenn ich "ein bisschen" spät zur Party bin, ich habe das gelöst indem ich einfach den "Fernzugriff" in Plex deaktiviert habe. Hört sich unlogisch an, ist aber so. Dadurch benutzt Plex nicht mehr was Plex nutzen will und ich kann ganz normal über meine eigene Domain, Port 443 und npm (Proxy Host, https://interneIP:32400 ) gehen. Ohne weitere Eintragungen, ohne zusätzliche Parameter oder ähnliches. Da ich die Domain, wie Du, in Plex über Netzwerk -> "Eigene URLs für den Zugriff auf diesen Server" propagiert habe (allerdings ohne Leerzeichen nach dem "," - kA, ob das einen Unterschied macht), funktioniert trotzdem noch der Zugriff über plex.tv, obwohl "Fernzugriff" deaktiviert ist.

OK...krass. Nein, so viel Arbeit hätte/habe ich mir nicht gemacht. Dazu kommen ja noch andere Shares, die einkalkuliert und erweitert werden müssen...das wäre nichts für mich. 🙂 Das mit dem Remote-Abgleich ist ein gutes Argument. Jetzt wo ich darüber nachdenke ist das mit dem "Lösch die Datei auf dem Array und erstell sie auf dem Cache neu" beim Überschreiben vielleicht doch gar nicht so unpraktisch - irgendwie. Dann werden die zuletzt veränderten Dateien entweder vom Cache Pool oder von - im Normalfall - einer zusätzlichen Platte geladen. Die Platten und der Strom werden es mir nicht danken, wenn sie "unnötig" geweckt werden, aber...das Leben ist hart. Verflucht, gerade die zweite 2TB SSD gekauft, nun heißt es wohl auf 2x 4TB sparen (bzw. auf ein gutes Angebot warten). 🙃 Wo die Daten liegen ist für mich nicht relevant. Ich hatte vor vielen, vielen, vielen Jahren schon unter Windows Home Server angefangen die Platten mit "Drive Bender" zusammenzufassen, als mir das Plattenjonglieren begann auf den Keks zu gehen. Mit normalem Linux dann nicht mehr, bis es mich wieder hart genervt hat, so dass ich mich umgesehen habe und bei unRAID gelandet bin. Unter unRAID habe ich mir direkt abgewöhnt in "Platten" zu denken und nur noch in Shares/Storage. Ich lasse einmal täglich ein Script die Inhalte der Disks in eine Datei auf den Cachepool schreiben. Dank Cache Directories bleibt das Array stumm und die Datei ist in wenigen Sekunden erstellt. Aber das zeigt einfach nur wieder: Jeder wie er mag. 🙂

Das habe ich früher so gemacht und da läuft man irgendwann in das Problem, dass die Platte A-M voll ist. Dann fängt man an rumzuschieben oder eine weitere Platte mit A-M anzulegen, dann ist 'ne Woche später N-Z voll und man hängt noch eine Platte rein, obwohl auf A-M noch 90% frei sind und so geht das immer weiter. Zusätzlich muss man beim Kopieren darauf achten, ob die Ordner/Dateien vielleicht auf Platte A, C, E bereits vorhanden sind usw. Die Lösung? unRAID und seine automatische Verteilung mittels Shares, die ja eigentlich genau all das (und noch mehr) für einen übernimmt. Ist der unterste Balken gut gefüllt, packt man eine weitere Platte dazu und das Thema ist erledigt. Das ist neben der Einfachheit auch noch effizient...finde ich zumindest. 🙂 Der Cache ist mit 2TB im Normalfall für 1-2 Wochen ausreichend, nur selten wird es mal knapp und in Ausnahmefällen deaktiviere ich ihn halt für das jeweilige Share, aktiviere Reconstruct Write und schreibe direkt aufs Array. Ansonsten läuft mein Array in read/modify/write. Ja, zugegeben, 4 TB fände ich auch besser, aber im Moment muss das erstmal so reichen. Und damit es möglichst selten knapp wird, nutze ich das Mover Tuning Plugin und lasse öfter prüfen, ob verschoben werden muss...und verschiebe dann nach Alter, um die neuesten Dateien möglichst lange auf den SSDs zu halten. Da ich die 2 TB SSDs noch nicht lange als Cache-Pool einsetze, geht da bestimmt noch ein bisschen was in Sachen Feineinstellungen. Ich erkläre mich und meine Gedankengänge gerne ausführlich (wie man merkt), da man mangels Wissen manchmal nicht nach dem fragt, das man eigentlich wissen will, sondern nach dem, das man meint wissen zu wollen....äh ja. 😄 Solltest Du das als Beschwerde aufgefasst haben, tut es mir leid, das war nicht die Intention. Eigentlich hatte ich eine Wall of Text der sich wiederholenden Erklärungen geschrieben, aber dabei ist mir etwas bewusst geworden (das was Du schon gesehen hast): Mein Problem ist ja nicht das eigentliche Kopieren, sondern das Überschreiben von Dateien und das kann ich bei Mammut-Kopierereien direkt auf das Array bestimmt mittels der von Dir erwähnten Option --delete-before oder ansonsten irgendeinem anderen Parameter in den Griff bekommen. Dann habe ich, wenn ich es richtig verstehe, nur noch den Fall, dass bei einem Wechsel der Festplatten aufgrund der "High Water"-Regel eine Überschneidung passieren kann. Aber das sollte so selten geschehen, dass es mir wurscht ist. Und wenn der Reconstruct-Kopiervorgang bei 10TB aufgrund der Löschungen und Plattenwechsel eine oder zwei Stunden länger dauert ist das völlig ok. Das ist so viel besser als 3 Tage anstatt 12-13 Stunden zu dauern. ^^ Und ich muss keine zentrale Funktion ändern, die sich bei meinem Glück nachher Gott weiß wie auswirkt. Bez. "auf dem Array löschen und auf dem Cache Pool neu schreiben" werde ich mal schauen, da geht bestimmt auch was mit dem von Dir vorgeschlagenen oder anderen Parametern. Und sollte ich trotz der geringen Source-Übertragungsgeschwindigkeit in das Parallel-Problem laufen, ist das aufgrund der zu überschreibenden Datenmenge nicht das Ding. Wenn man dem RAM-Write-Cache mittels rsync einen "Direkt durchschleusen, bitte"-Parameter übergeben könnte, das wäre vielleicht noch cool. Mal schauen, ob sowas geht.

Hm, ich möchte es nicht unbedingt "Fehler 40" ("Der Fehler sitzt 40cm vor dem Monitor") meinerseits nennen, aber nein, nutze ich nicht. Dass erst eine Temp-Datei erstellt wird wusste ich, dass sie im Cache erstellt wird macht Sinn. Dass bei Abschluss vermutlich nicht die Datei im Array ersetzt wird, damit hätte ich allerdings nicht gerechnet und daher auch nicht erwartet, dass es an rsync liegt. Ich werde es mir anschauen und mit den von Dir genannten und falls nicht erfolgreich mit anderen Parametern rumprobieren. 32GB und ich verstehe Deinen Punkt, jetzt wo ich um den RAM-Cache weiß. Aber eigentlich widerstrebt es mir den RAM zu erhöhen, nur um sauber kopieren zu können bzw. wenn ich große Kopieraktionen anliegen habe bräuchte ich vermutlich mehr RAM als das Board verträgt. 🙂 Aber wenn man es nicht ändern kann ist das halt so und die Verringerung der Dirty Pages macht das Ganze für Großaktionen erträglich. Ich war halt der Meinung, dass der RAM-Cache auf dem Array mehr schadet als nützt und eventuell "einfach" deaktiviert werden kann. Wie gesagt, solche großen Kopieraktionen habe ich selten und beim "Tagesgeschäft"-Kopieren werde ich mir Deine Rechenidee zunutze machen und wenn es sich sinnvoll ausgeht nochmal 32 GB nachschieben. 80 bzw. 85 oder 86 sind bei mir normal, da ich extra auf die Drehzahl geachtet habe, als ich das anfängliche Platten-Sammelsurium ersetzt und mich informiert habe, warum denn die Übertragungsgeschwindigkeiten sind wie sie sind (früher waren es nämlich 40-60). Das passt soweit auch. Nope, derzeit sind es 96TB, aber da ich jetzt von 10TB auf 16TB schwenke, wird der Endausbau 10x16TB sein...Stand heute. Das größte Share ist 42TB und wird mindestens 3x pro Woche abgeglichen, danach kommt eins mit 12TB und dann "Kleinvieh". Spiel-Mitschnitte (roh und bearbeitet), Filme, Serien, Videos, Backups für Freunde und Familie, da kommt schnell eine Menge zusammen. Ich könnte das sicher noch aufteilen und mehrere Shares mit gleichartigem Inhalt auf einzelnen Platten erstellen, aber dann könnte ich auch einfach mit den Platten und damit verbundenen Einschränkungen arbeiten, wie bei "jedem anderen" OS. Wie gesagt, Parity-Absicherung trotz "Plattengröße egal" und der hinter den Shares stehende "Speicher einfach"-Gedanke in Verbindung mit Cache und Array sind für mich die Haupt-Features, weshalb ich unRAID nutze - der Rest ist Bonus. Aber ich wollte auch keine Grundsatzdiskussion auslösen. Mir ging es eigentlich nur darum, dass meiner Meinung nach Vorgänge bez. des Arrays ablaufen, die kontraproduktiv sind, und ob man diese grundlegend ändern kann. Geht halt in einem Fall nicht so wie ich mir das vorstelle, aber dank Deiner Hilfe habe ich jetzt ein paar Ansätze wie ich das Ganze umschiffen kann. 🙂

Mache ich ja nicht. Ich gleiche einen Ordner mittels rsync mit einem Share ab und durch den RAM-Cache wird das (Über-)Schreiben der zweiten Datei gestartet, bevor die erste komplett auf der Platte gelandet ist. Somit verursacht das Linux-Feature eine massive Verschlechterung der Performance bei Nutzung von - für mich - essentiellen unRAID-Features und das empfinde ich als unlogisch, daher versuche ich es zu ändern. Geht das nicht ist es halt so und ich nehme die bestmögliche Variante. 🙂 Sobald 160 TB HDDs in bezahlbaren Regionen angekommen sind, werde ich gerne meine Shares auf nur einer Platte betreiben (wobei ich wetten könnte, dass parallel auf der gleichen Platte geschrieben wird, was auch wieder für'n Arsch ist). Das ist soweit korrekt, deshalb ist es mir auch ewig nicht aufgefallen, da ich ja normaler Weise auch mit Cache=Yes arbeite. Als ich dann 10TB per USB abgeglichen habe, habe ich gleich auf Cache=No umgestellt, da der Cache sowieso übergelaufen wäre. Als mir unRAID anzeigte, dass ich mit weniger als 40 anstatt 85 bzw. 250 MB/s schreibe, dachte ich mir: "Ich glaube nicht, dass das so sein soll." Ja, das kommt nur selten vor, aber auch hier gilt: Wenn ich es passend machen kann, mache ich es passend. 🙂 Danke für die Erklärung. 🙂 Deshalb war mein Gedanke das Ganze nur für das Array zu deaktivieren und nicht über die systemweiten Dirty Pages. Wenn dadurch SMB -> Array-Aktionen in die Hose gehen, hat man natürlich wieder nichts gewonnen...außer SMB macht außer zu löschen nichts auf dem Array. ^^ SMB oder NFS über Wireguard (bin grad nicht sicher, ich baue wegen Wireguard-SMB-Problemen viel hin und her). Durchgeführt über das UserScripts-Plugin mittels rsync. Ich versuche das Ganze nachzustellen und berichte. Schade Schokolade, dann werde ich wohl damit leben müssen und an den Dirty Pages rumfummeln, wenn ich es brauche. Oder ich muss doch wieder anfangen mir Todesscripte zu bauen, aber eigentlich nutze ich unRAID und dazugehörige Features, um das nicht mehr machen zu müssen (bzw. nur bei Dingen, die nicht als Feature vorhanden sind).

Moin, moin, ich hatte bereits einen Thread im englischsprachigen Bereich eröffnet und das grundlegende "Problem" wurde analysiert, aber ich glaube da ist so viel los, dass eine Weiterverfolgung schwierig wird. Und wir haben hier ja wirklich eine gute, aktive deutsche Moderation...das bin ich bei englischsprachigen Software-Herstellern nicht gewohnt. Vielen Dank schon mal dafür! 👍🙂 Nun aber zu meinem Problem: Wenn ich auf das Array schreibe verringert sich die grundsätzliche Schreibleistung durch multiple parallele Schreibprozesse aus dem RAM Write Cache beim Überschreiben von Dateien auf unterschiedlichen Platten drastisch. Reconstruct Write wird deaktiviert, "Normal" läuft halb so schnell, irgendwie macht das Feature für meinen Anwendungsfall alles nur langsamer und nicht schneller. Das Array ist für mich mehr ein Datengrab (das auch mal aktualisiert wird), alle schnell und oft im Zugriff befindlichen Dateien sind auf den Cache-SSDs. Von daher war meine Überlegung den Write Cache für das Array zu deaktivieren, damit nicht unnötig "auf der Parity rumgebumst" wird (2-3 Platten schreiben gleichzeitig) und auch Reconstruct Write zuverlässig funktioniert. Ich habe das Ganze durch den englischen Post per Tips&Tweaks-Plugin und die Dirty Ratios erstmal einigermaßen nutzbar gemacht, aber das betrifft ja das komplette System und 100%ig funktioniert es auch nicht. Leider bekam ich auf folgendes keine Antwort mehr: Gem. meiner Google-Recherche kann man den RAM Write Cache für einzelne Platten wohl beim Mounten per "-o sync" deaktivieren. Die Manipulation des Array-Mountens geht dann doch ein bisschen über meine "Frickelwohlfühlzone" hinaus. Daher meine Fragen (endlich ): 1. Wie deaktiviert man den RAM Write Cache für das Array richtig und gefahrlos? 2. Weil es mir gerade einfällt...kann man das (mir neue) Verhalten von unRAID abstellen, dass beim Überschreiben bei "Use Cache = Yes"-Shares die Ursprungsdatei auf dem Array gelöscht und auf dem Cache neu erstellt wird? Ich bin mir ziemlich sicher, dass unRAID früher direkt auf die jeweilige Platte geschrieben hat. Mir ist zwar klar, dass mit dem Löschen und neu anlegen die Geschwidigkeit stark erhöht werden kann, Kopiervorgänge Richtung unRAID sind für mich aber Geschwindigkeits-technisch ziemlich irrelevant (im Gegensatz zu Kopiervorgängen innerhalb unRAID). Das Einzige, das für mich bei diesem Vorgehen passiert ist, dass die Platte trotzdem an geht (nur um einen Löschvorgang durchzuführen) und die Cache-SSDs mit aktualisierten Alt-Daten, anstatt mit wirklichen Neu-Daten, gefüllt werden.