Wireguard (oder SMB? oder X?) IOWAIT bis zum Kollaps


Torben

Recommended Posts

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.

Link to comment

Du leidest vermutlich unter dem SHFS Overhead. Dieser entsteht, wenn man über den Pfad /mnt/user Daten transferiert. Entweder hat man eine sehr starke CPU (welche hast du?) oder man nutzt Disk Shares / Disk Pfade wie zb /mnt/cache oder /mnt/disk3. Mehr dazu auch in meinem Guide:

 

4 hours ago, Torben said:

250-270 MBit/s

Mbit oder MB? 1G oder 10G LAN?

Link to comment

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.

 

 

8 minutes ago, mgutt said:

Mbit oder MB? 1G oder 10G LAN?

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.

Link to comment

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. 🤯

Link to comment
3 hours ago, Torben said:

in htop und top sieht man das komischer Weise nicht

Dann könnte es ein Kernel Prozess sein, aber top zeigt die eigentlich an. In htop muss man Shift+K drücken, damit diese angezeigt werden. Falls du sonst den Load im Dashboard meinst: Der enthält iowait, weshalb der nicht nur die CPU abbildet.

 

10 hours ago, Torben said:

2x verschlüsselte Samsung 870 SSD im RAID 1

Könnte vielleicht eine fehlende Hardware-Beschleuningung von luks:btrfs sein. Sollte man dann aber wie gesagt durch eine hohe Prozesslast in htop sehen können.

 

Am besten mal mit einer einzelnen NVMe alle drei Varianten testen:

- xfs

- luks:xfs

- luks:btrfs

 

Ansonsten vielleicht auch mal das versuchen:

https://serverfault.com/questions/1012566/luks-high-transfer-rates-followed-by-high-io-wait

Link to comment
10 hours ago, mgutt said:

Dann könnte es ein Kernel Prozess sein, aber top zeigt die eigentlich an. In htop muss man Shift+K drücken, damit diese angezeigt werden. Falls du sonst den Load im Dashboard meinst: Der enthält iowait, weshalb der nicht nur die CPU abbildet.

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. 😄

 

10 hours ago, mgutt said:

Am besten mal mit einer einzelnen NVMe alle drei Varianten testen:

- xfs

- luks:xfs

- luks:btrfs

 

Ansonsten vielleicht auch mal das versuchen:

https://serverfault.com/questions/1012566/luks-high-transfer-rates-followed-by-high-io-wait

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.

Edited by Torben
Link to comment
1 hour ago, Torben said:

Dirtypages gleich mal auf 0 gesetzt.

Das habe ich auch mal getestet und die Performance ist dann miserabel. Man sollte denke ich mindestens 100 MB einstellen:

https://forums.unraid.net/topic/97165-smb-performance-tuning/?do=findComment&comment=898134

 

Dann sammelt der erstmal 100MB im RAM und schreibt sie sequentiell weg. Bei 0 geht wirklich jeder Chunk 1:1 zur Platte und selbst SSDs können sehr langsam sein, wenn das kleine Blöcke sind.

Link to comment

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): 

 

 

Link to comment

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?

Link to comment

SMB Version ermitteln (Unraid 6.9.2):

smbstatus
Samba version 4.12.14

 

Neueste Samba Version installieren:

https://slackware.pkgs.org/current/slackware-x86_64/samba-4.14.6-x86_64-1.txz.html

https://slackware.pkgs.org/current/slackware-x86_64/icu4c-69.1-x86_64-1.txz.html (muss ebenfalls aktualisiert werden)

https://slackware.pkgs.org/current/slackware-x86_64/glibc-2.33-x86_64-3.txz.html (muss ebenfalls aktualisiert werden)

wget https://slackware.uk/slackware/slackware64-current/slackware64/n/samba-4.14.6-x86_64-1.txz -P /tmp
upgradepkg --install-new /tmp/samba-4.14.6-x86_64-1.txz
wget https://slackware.uk/slackware/slackware64-current/slackware64/l/icu4c-69.1-x86_64-1.txz -P /tmp
upgradepkg --install-new /tmp/icu4c-69.1-x86_64-1.txz
wget https://slackware.uk/slackware/slackware64-current/slackware64/l/glibc-2.33-x86_64-3.txz -P /tmp
upgradepkg --install-new /tmp/glibc-2.33-x86_64-3.txz

 

Ergebnis:

smbstatus
Samba version 4.14.6

 

Die Frage ist nun wie man Samba 4.12.14 in Unraid 6.8.3 installiert bekommt. Bei Slackware gibt es entweder nur 4.4.4 oder 4.14.6. Oder man aktualisiert beide Unraid Versionen auf 4.14 und testet dann. Denk dran, dass Updates nach einem Neustart verloren gehen.

 

@ich777 Sind FreeBSD txz Pakete in Slackware nutzbar? Dann könnte man es mit Samba 4.12.15 probieren.

Link to comment
7 minutes ago, mgutt said:

@ich777 Sind FreeBSD txz Pakete in Slackware nutzbar? Dann könnte man es mit Samba 4.12.15 probieren.

Nein, BSD ≠ Linux und würd ich auf keinen Fall mischen!

 

Außerdem bitte auf keinen Fall machen da die unRAID SAMBA version speziell für unRAID kompiliert worden ist und du das System aus dem Gleichgewicht bringst bzw. dir du dir sogar evtl. irgendwas zerschießen könntest...

 

7 minutes ago, mgutt said:

?

 

Das würd ich auf keinen Fall machen, wenn du die Version änderst funktionieren die anderen Pakete nicht mehr die auf der vorherigen Version von basieren wenn sie denn glbic benötigen.

Das ist hier ein Spiel mit dem Feuer... :D

 

 

Würde es nicht mehr Sinn ergeben die 6.10.0-rc1 zu installieren, die hat SAMBA: version 4.12.15

Link to comment
1 hour ago, mgutt said:

Wie sind deine genauen Test-Bedingungen? Du hast einen verschlüsselten SSD Cache im BTRFS RAID1. Auch ein verschlüsseltes Array? Ich würde das gerne nachstellen, dann können wir ja uns ja austauschen.

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. 🙂

Edited by Torben
Link to comment
5 minutes ago, ich777 said:

?

Ja, muss auch aktualisiert werden. Ansonsten bekommt man einen glibc Fehler, wenn man den smbstatus laden möchte.

 

5 minutes ago, ich777 said:

Das würd ich auf keinen Fall machen, wenn du die Version änderst funktionieren die anderen Pakete nicht mehr die auf der vorherigen Version von basieren wenn sie denn glbic benötigen.

Das ist ja nur ein Testserver.

 

13 minutes ago, mgutt said:

Die Frage ist nun wie man Samba 4.12.14 in Unraid 6.8.3 installiert bekommt.

Ich habe nun alte Samba Pakete gefunden:

https://slackware.uk/cumulative/slackware64-current/slackware64/n/

 

Allerdings gibt es nur 4.12.5 oder 4.13.0

image.png.70a19f597748460826363c8765617f37.png

 

Die exakt gleiche Version wie in Unraid 6.9.2 bekommt man nicht in 6.8.3 installiert. Also wäre es denke ich das beste, wenn man für einen Test beide auf 4.13.0 aktualisiert und dann vergleicht. Das wäre dann der Link:

https://slackware.uk/cumulative/slackware64-current/slackware64/n/samba-4.13.0-x86_64-1.txz

 

1 minute ago, Torben said:

nur eine nVme als Array-Disk

Ok. Also auch kein Cache? Dann passt das ja. Ich habe aktuell nur eine SATA SSD im Array des Testservers, aber die wäre ja wenn einfach nur langsamer als bei deinen Tests.

 

Und sonst einfach eine VPN Verbindung per Wireshare in den Grundeinstellungen und dann per rsync einen Ordner syncen? Große oder kleine Dateien ist egal? rsync schickt oder holt ab? Das ganze dann über SMB?

 

 

Link to comment
10 minutes ago, ich777 said:

Würde es nicht mehr Sinn ergeben die 6.10.0-rc1 zu installieren, die hat SAMBA: version 4.12.15

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". 🙂

Link to comment
6 minutes ago, mgutt said:

Ja, muss auch aktualisiert werden. Ansonsten bekommt man einen glibc Fehler, wenn man den smbstatus laden möchte.

Trotzdem, damit funktionieren dann alle anderen sachen nciht mehr die die "alte" glibc version verwenden und damit schießt du man sich selbst wieder ins knie denn evtl. funktioniert dann die andere Software die das verursacht nicht mehr.

 

Just my 2 Cents...

Link to comment
5 minutes ago, mgutt said:

Ok. Also auch kein Cache? Dann passt das ja. Ich habe aktuell nur eine SATA SSD im Array des Testservers, aber die wäre ja wenn einfach nur langsamer als bei deinen Tests.

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. 🙂

 

6 minutes ago, mgutt said:

Und sonst einfach eine VPN Verbindung per Wireshare in den Grundeinstellungen und dann per rsync einen Ordner syncen? Große oder kleine Dateien ist egal? rsync schickt oder holt ab? Das ganze dann über SMB?

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.

Link to comment
16 minutes ago, mgutt said:

dann per rsync einen Ordner syncen? Große oder kleine Dateien ist egal? rsync schickt oder holt ab? Das ganze dann über SMB?

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

Edited by Torben
Link to comment
  • 5 months later...

Komplett offtopic und es tut mir leid, dass dein Problem noch nicht gelöst ist, aber ich brech hier grade lachend vorm Rechner zusammen...

Hier musste ich schon schwer lachen:

On 8/8/2021 at 3:04 PM, Torben said:

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").

 

Aber spätestens hier war für mich dann komplett Sense:

On 8/9/2021 at 5:00 PM, Torben said:

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. 😄

 

Vielen Dank :D

Edited by jakami99
-
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.