[Sammelthread] 10Gbit Homenetzwerk

Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Gibt es eine Standalone-App, in das man viele, winzige Files schiebt, die von der App automatisch gepackt werden, bevor ich die Pakete übers Netzwerk schicke? Oder ist selbstprogrammieren angesagt?

Und ab welcher Filegröße habt ihr noch 10G? (kann es gerade nicht testen)
 
rsync mit schalter -z (für compress transfer) , gab es unter Linux denke ich schon seit 1998.
ab rsync 3.1 (2014 ?) kam dann der schalter compress-choice=(...) hinzu mit options: lz4 , zstd , zlibx

z.B: rsync -a --compress --compress-choice=zstd source/ user@host:/destination/

(Solche Tools sind u.a. der Grund warum Linux ein so gutes Arbeitspferd ist ... und es unter Win seit einiger Zeit sogar ein WSL gibt.)
 
Zuletzt bearbeitet:
Ja, .tar / Tarball könnte sein, was du suchst.

Beim Compress ist meiner bescheidenen Meinung nach LZ4 mit Abstand das beste/sinnvollste hinsichtlich Rechenleistungsbelastung. Gut komprimierbares Zeug wird damit annähernd so gut komprimiert wie mit zstd, schlecht komprimierbares Zeug wird mit zstd auch nicht wirklich besser. zstd tät ich nur nehmen, wenn die Leitung echt lahm ist und die Rechenleistung nicht das Thema ist.
Im Heimnetz oder mit einem zeitgemäßen Internetanschluss (nunja, wer hat das schon in AT/DE) dann eher LZ4.

Und ja, ich hab Folder mit viel Kleinscheiß drin fürs Langzeitbackup auch geTARt, weil SMB sonst eeeewig und 3 Tage gebraucht hätte.
 
@Dwayne_Johnson:
Eventuell brauchen wir mehr Randbedingungen.
Willst du die Datentransfers lokal machen (NAS<>Desktop), über welches Protokoll??
Da wüsste ich nix automatisches außer rsync.
smb und nfs weiß ich nicht und iscsi ist ja eh blockorientiert.

Normale Kopieraktionen von den Filemanagern komprimieren da auch nix, müsste ja auf der Gegenseite was geben, welches das wieder entpackt...
 
Pro-Tipp: für ne CI/CD Pipe solltest du dir was sinnvolleres als die Wolke und SMB suchen. :fresse:

Ansonsten:
SMB kann doch multi-path, eventuell gehts da bissi fixer, aber da glaube ich nicht dran.
Jedoch bin ich nicht so der SMB-Crack...

NFS ist keine Option?
Ansonsten hilft bei Source-Code wirklich nur ein manuelles tar.{b|g|x}z, dann wirds auch relativ fix beim übertragen.

Ich persönlich versuche viele kleine Dateien zu meiden wie die Pest, z.B. Replays, Configs oder Session Backups von den Browsern, die packe ich immer manuell in ein 7z...
Für Quellcode hab ich ne Forgejo-Instanz mit dem Runner, git packt ja vor der Übertragung auch alles in ein Archiv, das lüppt prima.
 
Zuletzt bearbeitet:
Normale Kopieraktionen von den Filemanagern komprimieren da auch nix, müsste ja auf der Gegenseite was geben, welches das wieder entpackt...
In manchen Fällen bräuchte ich etwas, dass viele, winzige Files automatisch packt und im Ziel gepackt bleibt (zb für die Cloud


Pro-Tipp: für ne CI/CD Pipe solltest du dir was sinnvolleres als die Wolke und SMB suchen. :fresse:
K.A. was damit gemeint ist - bin kein Network-Pro :fresse:


Ich persönlich versuche viele kleine Dateien zu meiden wie die Pest, z.B. Replays, Configs oder Session Backups von den Browsern, die packe ich immer manuell in ein 7z...
Lässt sich bei lokalen iTunes-Backups nicht vermeiden. Das hier ist nur ein kleiner Bruchteil von iTunes-Backups
 

Anhänge

  • Screenshot 2026-09-17 090329.png
    Screenshot 2026-09-17 090329.png
    7,5 KB · Aufrufe: 72
Zuletzt bearbeitet:
Lässt sich bei lokalen iTunes-Backups nicht vermeiden. Das hier ist nur ein kleiner Bruchteil von iTunes-Backups
...ich würde mir sowas ja nicht antun: NAS bauen, Jellyfin drauf und dann BorgBackup auf eine reingemountete grosse USB-Platte, feddich. Selbst auf Cloudspeicher (z.B.Hetzner Strorage Box) gehen Backups von Volumes mit hunderten Gigabytes innerhalb von wenigen Sekunden, wenn nur die täglichen Änderungen übertragen werden. Ansonsten gibt es auch tolle Skripte für inkrementelle Backups per rsync: Meine ca. 4 TB grosse Mediensammlung braucht damit ca. 20 Minuten für das inkrementelle Backup auf eine USB-Platte...
 
Inkrementelle iTunes-Backups habe ich auch...
Ich muss mir noch angewöhnen, in engeren Zyklen zu sichern, damit sich Änderungen zu keinem großen Batzen von 100G und mehr anstauen
 
In manchen Fällen bräuchte ich etwas, dass viele, winzige Files automatisch packt und im Ziel gepackt bleibt (zb für die Cloud
K.A. was damit gemeint ist - bin kein Network-Pro :fresse:
Lässt sich bei lokalen iTunes-Backups nicht vermeiden. Das hier ist nur ein kleiner Bruchteil von iTunes-Backups
1789747287228.png
Ich fühle mit dir.
Aber da ich seit Jahren nur inkrementelle Backups einmal die Woche mache, sind das immer nur so 10..15 GB an Änderungen...
Früher(tm) mit Duplicati und DejaDup, heuer mit der eingebauten KDE Sicherung...

CI/CD: Continuous Integration / Continuous Deployment -> Wenn ich eins meiner Git-Repos aktualisiere, rödelt die Pipeline den ganzen Kram einmal durch und am Ende habe ich das Ergebnis auf dem Server.
Da fliegen auch Millionen klitzekleiner Files durch die Gegend...
 
Ich kenne leider itunes-backup zuwenig, anhand Deiner Angaben vermute ich, das es einen Korpus aus vielen, vorkomprimierten Dateien hat (zumeist 1 Datei in 1 Datei komprimiert).
Weiters vermute ich, dass Du primär ein schnelles, komfortables Backup möchtest, wobei benötigter Speicherplatz eher sekundäre Rolle spielt.

Mit Archivern (tar, zip, rar, ...) hätte man zwar eine nette Verwaltungsgröße von 1 Datei (alles in 1 Datei zusammengerollt), jedoch müsste dadurch jedes mal die gesamte Datenmenge komplett neu übertragen und gelagert werden (= Zeit+Platz intensiv).
Etaige NAS Dateisystem-Features wie de-duplikation laufen hier ins leere (Daten nur um >= 1 Byte verschoben --> Filesystem-Datenblock hat andere CRC-Checksum)

(Gedankenspiel)
Riesige Dateianzahl akzeptieren und beibehalten, NAS Filesystem wäre ein ZFS dataset mit ausgeschalteter komprimierung, recordsize=16k (niedriger Wert bzw. optimierter Wert anhand Korpus) , User macht inkrementelle Spiegelungen (rsync oder Programm mit ähnlichen Funktionen) aufs NAS in 1 Verzeichnis, Dateien gleichen Namens,Dateigröße,Änderungsdatum werden als ident angesehen und für Übertragung übersprungen, mit ZFS-Snapshots (für Versionsverwaltung).
Dann würde beim Backup aufs NAS nur mehr die Differenz (=geänderte Dateien) übertragen, und ab ZFS-Snapshot auch nur mehr die (neuen) Änderungen ggü. Vorversion gespeichert. De-Deplizierung wäre sogar auch noch möglich (ich persönlich verwende de-dup nicht, da zu RAM-intensiv, dafür aber immer zfs-dataset mit eingeschalteter Kompression.)

z.B: rsync -a --dry-run --delete --info=progress2 /sourcepfad/zum/iTunesBackup/ /mnt/nas/iTunesBackup/
der Schalter "--dry-run" macht dies zum Test-Lauf, ohne Daten zu verändern (nur zum austesten verwenden).
 
Zuletzt bearbeitet:
Tools die auf Dateivergleich basieren, sind im Terabyte Bereich mit sehr vielen kleinen Dateien suboptimal.
Für das Backup sind eigentlich nur zwei Optionen schnell:

1. ZFS Replikation. Das arbeitet nicht mit Dateien sondern einem Datenstrom geänderter ZFS Datenblöcke seit dem letzten Snap. Damit läßt sich sogar der Maílserver einer großen Universität mit 10k User unter Volllast alle 10 Min mit einem Backup syncronisieren, inkl. offener Dateien im letzten Stand, z.B. mein gepuffertes napp-it cs-stream

2. Eventgesteuertes Sync. Das überwacht einen Ordner mit Unterordnern auf Änderungen und kopiert neue/geänderte Dateien in Echzeit auf ein Backup, z.B. Syncthing oder mein einfacheres napp-it cs-sync. Bei extrem vielen Dateien/Ordnern muss man testen ob der RAM dafür reicht.

3. Für reines file sync sind rsync, rclone oder robocopy da. Für rclone + Puffer für bessere Performance auch bei kleinen Dateien kann man mein cs-stream für rclone nehmen.

Die cs-tools sind Teil meiner web-gui, laufen aber auch standalone auf 8 OS Varianten inkl. Free-BSD, Linux, MacOS, Solaris und Windows.

 
Welchen Kernel hast du den da am Start?


"The RTL8159 requires firmware for the PHY in order to achieve a 10GBit link speed. Without firmware, only 5GBit were achieved. The firmware can be extracted from the out-of-tree r8152 driver-code where it is stored in the ram17 u8-array. Code is added to use the existing firmware upload mechanism of the driver for the RTL8157/9 PHY firmware code. The firmware will be submitted separately to linux-firmware."
Meh, hab jetzt mal einige Stunden damit verbracht, offenbar geht das erst mit Kernel 7.2 ... wann Porxmox den wohl bekommen wird? :fresse:
Könnte die NIC natürlich auch der TrueNAS VM geben, dort hätte ich dann überhaupt noch Kernel 6.. lol.
 
Nehm lieber gleich den DKMS-Treiber.
7.2 macht seit 7.2.3 Stress bei iSCSI unter Arch-Kerneln (getestet mit Cachy znver4 und Manjaro)...
Auf beiden Karten (8125 RJ45 und 8127a SFP+).
 
Du nimmst DEN Treiber?

Welchen Treiber nutzt die Karte jetzt?
Eventuell musst du den blacklisten, damit der Kernel den OOT-Treiber nutzt...
 
Zuletzt bearbeitet:
Eigentlich schon.
Hast dus selbst laufen oder ist das Vermutung?
Ich glaube irgendwie, dass das trotz dem Treiber erst mit Kernel 7.2 auf 10G läuft.. aber vllt. irre ich mich?
Der Phy läuft auf 10G, allerdings der USB nicht, der verbindet nur mit 5G USB. Kabel und Port ist auszuschließen, theoretisch kann er 10G, aber beim Verhandeln der Verbindung kommt 5G raus.
 
Najaaa, so gaaanz eindeutig war das für mich nicht. :fresse:
Dachte irgendwie ab 7.2 isses out of the box und vorher mit Gefrickel... aber offenbar nicht?
 
Na zum Glück gibt's Übersetzer, wenn man das "to support" nicht einordnen kann :hust:
Oder mal eins deiner unzähligen getesteten Modelle damit füttern :bigok:
Sorry 😅
 
Eigentlich schon.
Hast dus selbst laufen oder ist das Vermutung?
Ich glaube irgendwie, dass das trotz dem Treiber erst mit Kernel 7.2 auf 10G läuft.. aber vllt. irre ich mich?
Der Phy läuft auf 10G, allerdings der USB nicht, der verbindet nur mit 5G USB. Kabel und Port ist auszuschließen, theoretisch kann er 10G, aber beim Verhandeln der Verbindung kommt 5G raus.
Vermutung, ich nutze aktuell die r8127 und r8125 mit 7.2.8 cachy znver4 und in Verbindung mit PCIe, USB-Kram hab ich so schnellen nicht... =)
Wenn der USB selbst sich nicht mit genug Speed verbindet, könnte es auch am (USB-seitigen) Hub oder Kabel liegen?
 
Also ich weiss nicht, ich hab mir den verlinkten Artikel nochmal durchgelesen, und werde daraus nicht so schlau - ich bin aber auch kein Linux-Crack.

Für mich liest sich das so, als würde es mitm dkms Treiber schon vor 7.2 gehen und mit 7.2 ist er dann "baked in"...
Wenn der USB selbst sich nicht mit genug Speed verbindet, könnte es auch am Hub oder Kabel liegen?
Ja und nein, wäre naheliegend. Ich hab 2 Ports (A und C) probiert und hab unzählige Kabel getestet, sogar extra kurze 20G Kabel gekauft (2 verschiedene, keine Billigware, gute Bewertungen).
Der phy rennt mit 10G. Der Controller in der NIC bietet dieses SuperSpeedPlus bzw. 10000M an, der Hub kanns auch, aber die Verbindung wird nur mit SuperSpeed (5000M) hergestellt.
Qwen meint, das ist erst mit 7.2 gefixed, wobei ich mir da nicht so 100% sicher bin, wer traut so AI schon zu 100%.

Klar, mit Arch/Cachy/eOS/etc. bist fein raus.
 
Kommt drauf an, ob mit 7.2 nochwas am USB-Part geändert worden ist.
DKMS nimmt ja den externen Treiber und rödelt ihn als Modul in den aktuellen Kernel.

KI meint:
1790851468590.png

Der untere Teil gibt mir zu denken...
Beitrag automatisch zusammengeführt:

Da stehts auch nochmal, der Kernel braucht die extrahierte Firmware aus dem OoT-Treiber als Datei: /lib/firmware/rtl_nic/rtl8159-1.fw

Ergo, aus der r8152.c an Zeile 20788 das Array in ne Binär-Datei wandeln, umbenennen, rein kopieren, testen.
Beitrag automatisch zusammengeführt:

Habs mal extrahieren lassen...
(https://gitlab.com/koblitz-rtlnic/rtlnic_fw/)
Beitrag automatisch zusammengeführt:

---snip---

Klar, mit Arch/Cachy/eOS/etc. bist fein raus.
Cachy hat die betreffende Firmware-Datei noch nicht integriert
 

Anhänge

Zuletzt bearbeitet:
Hab's kurz mit Claude auf meinem Server auch durchgespielt, USB 10Gbits nimmt wie beschrieben nur 5Gbit her. Ich habe den Treiber als DKMS bauen lassen und das funktioniert.

Hinweis von mir, Realtek 2.22.1 verhindert bei mir höhere C package states. Ich bin zurück auf 2.21.4. damit geht auch C8 bei mir wieder.
 
Kleines Update. Die Base-T Module musste alle gehen und mussten 3 x TP-Link Omada MC420L 10G weichen. Hintergrund des ganzen, mein passiver Switch hat zuwenig Power und mir ist immer wieder Port 8 (das NAS) beim starten desselbigen abgenippelt. Ich Ärgere mich nur, das ich nicht von Anfang an auf die Konverter gegangen bin. Ich hatte nicht auf dem Schirm, das die ja schon ein Multi Gig PHY drin haben. Vorteil der Sache, die beiden extra Lüfter konnten abgebaut werden. Keine Port Abstürze mehr. Nachteil der Sache, jetzt 3 Module rumliegen zu haben ^^ Wer eines oder alle 3 braucht, VK Thread ist offen.
1791484548930.png
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh