Optional: Parallele Replikation mehrerer Datasets #10

Open
opened 2026-10-15 17:08:53 +02:00 by thorsten.spille · 1 comment

Viele Datasets werden heute strikt nacheinander übertragen.

Umsetzung:

  • Parameter parallel (Default 1 = heutiges Verhalten)
  • Schleifenkörper pro Dataset als Funktion, Gruppierung nach Tiefe (Eltern vor Kindern)
  • Rückgabewert pro Job per wait, Log pro Dataset gepuffert und am Stück ausgegeben
  • Send-Pipes ohne gemeinsamen ControlMaster

Rahmen: Default = bisheriges Verhalten, der Replikations-/Löschalgorithmus bleibt unverändert, optionale Tools werden per which erkannt (fehlen sie, läuft alles wie bisher mit Logmeldung). Eigener Branch/PR mit Test. Teil von 2.0.0, Reihenfolge siehe Roadmap.

Viele Datasets werden heute strikt nacheinander übertragen. **Umsetzung:** - Parameter `parallel` (Default 1 = heutiges Verhalten) - Schleifenkörper pro Dataset als Funktion, Gruppierung nach Tiefe (Eltern vor Kindern) - Rückgabewert pro Job per `wait`, Log pro Dataset gepuffert und am Stück ausgegeben - Send-Pipes ohne gemeinsamen ControlMaster --- **Rahmen:** Default = bisheriges Verhalten, der Replikations-/Löschalgorithmus bleibt unverändert, optionale Tools werden per `which` erkannt (fehlen sie, läuft alles wie bisher mit Logmeldung). Eigener Branch/PR mit Test. Teil von 2.0.0, Reihenfolge siehe Roadmap.
thorsten.spille added this to the 2.0.0 milestone 2026-10-15 17:08:53 +02:00
thorsten.spille changed title from Parallele Replikation mehrerer Datasets to Optional: Parallele Replikation mehrerer Datasets 2026-10-15 23:45:33 +02:00
thorsten.spille removed this from the 2.0.0 milestone 2026-10-15 23:45:33 +02:00
Author
Owner

Zurückgestellt als optional, nicht Teil von 2.0.0 (wie die MPTCP-Idee #27). Lohnt erst bei vielen kleinen Datasets und sehr hoher verfügbarer Bandbreite; der Großteil der Installationen hängt an Gigabit oder WAN, wo die Leitung der Engpass ist und parallele Streams sie nur teilen. Gewinn wäre vor allem weniger Leerlauf pro Dataset (im Testlog ~5–6 s je Dataset ohne nennenswerte Daten).

Zurückgestellt als **optional**, nicht Teil von 2.0.0 (wie die MPTCP-Idee #27). Lohnt erst bei vielen kleinen Datasets und sehr hoher verfügbarer Bandbreite; der Großteil der Installationen hängt an Gigabit oder WAN, wo die Leitung der Engpass ist und parallele Streams sie nur teilen. Gewinn wäre vor allem weniger Leerlauf pro Dataset (im Testlog ~5–6 s je Dataset ohne nennenswerte Daten).
Sign in to join this conversation.
No labels
bug
enhancement
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
bashclub/zsync#10
No description provided.