{webdav, davfs2] extrem langsam trotz hoher Bandbreite

[Diedrich Ehlerding]

Ich habe nun einen Glasfaseranschluss und angeblich 50 (laut Vertrag)
bzw. 60 (laut diveresen Speedtestseiten und laut Fritzbox) upstream.

Ich habe daraufhin den Platz in der "Magentacloud" per davfs2 gemountet.
Geht auch im Prinzip. Den wollte ich als Datensicherungsplatz benutzen.
Soweit so gut ... Ich habe nun Dateien, die ich für sicherungswürdig
halte, lokal (auf meiner SSD) in ein tar.gz-Archiv gepackt, das ist ca
250 MByte groß geworden. Kopiere ich dieses Archiv mit cp in das
gemountete davfs2-Verzeichnis, ist der Befehl cp nach wenigen sekunden
fertig ... und bläst natürlich erstmal nur den memorycache zu. Es dauert
ewig und drei Tage bis ich das webdav-Verzeichnis wieder umounten kann;
und die ganze Zeit ist in der Fritzbox der uplink mit 60 MBit
ausgelastet.

Rechnerisch müssten 250 MByte undefähgr 2500 MBit ergeben, das sollte
also etwas mehr als 40 Sekunden dauern, wenn der upstream 60 MBit
leistet - hätte ich gedacht. . Es dauerte aber mehr als 100 Minuten,
bis der memorycache auf das ferne Gerät geschrieben war.

Um das noch etwas besser zu hinterlegen, kopiere ich nun die DSatei mit
dd if=<lokale> of=/mnt/<mountpoint>/<Zielname> bs=1M oflag=direct
letzteres damit nicht der memorycache vollgeblasen wird, sondern beim
Ende des dd auch die Daten auf dem fernen system sind. Wieder ist der
upstream vollständig unter Last, aber wieder dauert es nicht 100
Sekunden, sondern seeeeeeehr viiiiiel läääääänger, um ca 2
Zehnerpotenzen länger, obwohl wieder fast während der gesamten Zeit laut
Fritzbox der uplink voll ausglastet ist.

Schließlich ist alles fertig ... und dd behaupotet:
259062444 bytes (259 MB, 247 MiB) copied, 0.381196 s, 680 MB/s

ich hatte es allerdings mit "time dd" gestartet ... und time sagt: es
hat 10 Minuten und ein paar Sekunden gedauert ... Warum, was macht er da
auf der upstream-Leitung?

Ich verstehe ja, dass so ein Konstrukt wie davfs2 (über https) Overhead
verursacht, aber Overhead um den Faktor 150 oder mehr auf der Leitung?
Was ist da los; was kann/sollte ich da ändern? Sollte ich anderer
Blockgrößen, andere Mountoptionen
wählen (Ich abe nur "user,noauto" angegeben)? Wo ist mein Denkfehler?
--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.

[Dieter Schmickler]

Am 04.07.22 um 22:16 schrieb Diedrich Ehlerding:

> Was ist da los; was kann/sollte ich da ändern?

Versuch doch mal die Alternative "nextcloud-desktop". Das funktioniert
bei mir um Klassen besser als mit davfs2. Seit der Umstellung von
Magentacloud hast Du jetzt einen Nextcloudspeicher.

[Marco Moock]

Am Mon, 04 Jul 2022 22:16:33 +0200
schrieb Diedrich Ehlerding <diedrich....@t-online.de>:

> Rechnerisch müssten 250 MByte undefähgr 2500 MBit ergeben, das sollte
> also etwas mehr als 40 Sekunden dauern, wenn der upstream 60 MBit
> leistet - hätte ich gedacht. . Es dauerte aber mehr als 100 Minuten,
> bis der memorycache auf das ferne Gerät geschrieben war.

2000 MBit, 1 Byte=8 Bit.
Bei 50 MBit/s sind das 40 Sekunden. Da ist aber der Overhead der ganzen
Protokolle nicht mit eingerechnet.
Ich weiß zudem nicht, wie WebDAV genau funktioniert und implementiert
ist.
Teste mal mit bmon und ggf. nethogs, ob das auch wirklich der
webdav-Upload ist.

[Ulli Horlacher]

Marco Moock <mo...@posteo.de> wrote:

> Teste mal mit bmon und ggf. nethogs, ob das auch wirklich der
> webdav-Upload ist.

Fuer reinen tcp Durchsatz:

https://flupp.belwue.de/tcpbm


--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: horl...@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/

[Diedrich Ehlerding]

Marco Moock meinte:

> Teste mal mit bmon und ggf. nethogs, ob das auch wirklich der
> webdav-Upload ist.

Bevor mein dd loslief, war die Leitung laut Fritzbox leer.

[Diedrich Ehlerding]

Diedrich "Ingrid" Ehlerding meinte:

[davfs2-Probleme]

Ich glaube, ich habs gefunden.

davfs hält allerlei Caches vor . Die werden bei Gelegenheit gesynct ...
und da standen von früheren Versuchen noch sehr dicke Dateien drin.
anscheinend wurden die nie wirklich ordentlich übertragen, und
dementsprechend startete diese Synchronisation immer wieder neu ...

Nachdem ich diese caches (~/.davfs2/cache/*) dann gelöscht hatte, läuft
es in der erwarteten Geschwindigkeit.

[Ulli Horlacher]

Diedrich Ehlerding <diedrich....@t-online.de> wrote:

> davfs hält allerlei Caches vor . Die werden bei Gelegenheit gesynct ...
> und da standen von früheren Versuchen noch sehr dicke Dateien drin.
> anscheinend wurden die nie wirklich ordentlich übertragen, und
> dementsprechend startete diese Synchronisation immer wieder neu ...

Weil davfs kein Wiederaufsetzen nach Verbindungsabbruch vorsieht?
Der uebliche Protokoll-Design-Bug also :-}

Einer der vielen Gruenden warum ich so einen Mist nicht verwende.

[Arno Welzel]

Ulli Horlacher:

> Diedrich Ehlerding <diedrich....@t-online.de> wrote:
>
>> davfs hält allerlei Caches vor . Die werden bei Gelegenheit gesynct ...
>> und da standen von früheren Versuchen noch sehr dicke Dateien drin.
>> anscheinend wurden die nie wirklich ordentlich übertragen, und
>> dementsprechend startete diese Synchronisation immer wieder neu ...
>
> Weil davfs kein Wiederaufsetzen nach Verbindungsabbruch vorsieht?
> Der uebliche Protokoll-Design-Bug also :-}

Das hat weniger mit dem Protokoll zu tun, als der Frage, wie mit dem
Ergebnis umgegangen werden soll.

Wenn man eien Datei sendet und die Übertragung von 30% abbricht, sind im
Ziel nur 30% der Datei vorhanden. Da die Operation "Datei senden" aber
atomar sein muss, kann man im Ziel nicht einfach mal diese 30% liegen
lassen und hoffen, dass irgendwann mal der Rest nachgereicht wird und
die Datei bis dahin ewig liegen lassen.

> Einer der vielen Gruenden warum ich so einen Mist nicht verwende.

Die Alternative beim OP wäre halt gewesen, dass er jetzt etliche
Fragmente unvollständig hochgeladener Dateien auf dem Server hätte und
diese manuell aufräumen muss, wenn er sie nicht wirklich übertragen will.

Wenn man große Datenmengen senden möchte und sichergehen muss, dass auch
Teilübertragungen und Wiederaufsetzen nach Abbruch möglich ist, nimmt
man eben nicht WebDAV. Wenn man aber Abbruch explizit vorsieht, sollte
der Server mit solchen Teilübertragungen auch irgendwie sinnvoll umgehen
und diese nicht ewig herumliegen lassen, sondern z.B. nach einer
einstellbaren Wartezeit auch aufräumen. Dazu muss er natürlich auch
wissen, welche Dateien bereits fertig übertragen wurden und welche
nicht. Ein simples "ich sende mal Daten und wenn im Ziel die Datai schon
vorhanden ist, fange ich eben erst da an, wo noch was fehlt" reicht dann
nicht.


--
Arno Welzel
https://arnowelzel.de

[Ulli Horlacher]

Arno Welzel <use...@arnowelzel.de> wrote:
> Ulli Horlacher:
>
> > Diedrich Ehlerding <diedrich....@t-online.de> wrote:
> >
> >> davfs hält allerlei Caches vor . Die werden bei Gelegenheit gesynct ...
> >> und da standen von früheren Versuchen noch sehr dicke Dateien drin.
> >> anscheinend wurden die nie wirklich ordentlich übertragen, und
> >> dementsprechend startete diese Synchronisation immer wieder neu ...
> >
> > Weil davfs kein Wiederaufsetzen nach Verbindungsabbruch vorsieht?
> > Der uebliche Protokoll-Design-Bug also :-}
>
> Das hat weniger mit dem Protokoll zu tun, als der Frage, wie mit dem
> Ergebnis umgegangen werden soll.
>
> Wenn man eien Datei sendet und die Übertragung von 30% abbricht, sind im
> Ziel nur 30% der Datei vorhanden. Da die Operation "Datei senden" aber
> atomar sein muss, kann man im Ziel nicht einfach mal diese 30% liegen
> lassen und hoffen, dass irgendwann mal der Rest nachgereicht wird und
> die Datei bis dahin ewig liegen lassen.

Ein vernuenftiges Protokoll mit vernuenftiger Implementierung
beruecksichtigt das. Sonst waere WAN-Transfer im Multi-TB Bereich kaum
moeglich.

> > Einer der vielen Gruenden warum ich so einen Mist nicht verwende.
>
> Die Alternative beim OP wäre halt gewesen, dass er jetzt etliche
> Fragmente unvollständig hochgeladener Dateien auf dem Server hätte und
> diese manuell aufräumen muss, wenn er sie nicht wirklich übertragen will.

Bei einem vernuenftigen Protokoll mit vernuenftiger Implementierung
passiert das automatisch.

> Wenn man große Datenmengen senden möchte und sichergehen muss, dass auch
> Teilübertragungen und Wiederaufsetzen nach Abbruch möglich ist, nimmt
> man eben nicht WebDAV.

Eben. Sag ich doch :-)

[Jan Novak]

Am 05.07.22 um 10:49 schrieb Ulli Horlacher:

> Diedrich Ehlerding <diedrich....@t-online.de> wrote:
>
>> davfs hält allerlei Caches vor . Die werden bei Gelegenheit gesynct ...
>> und da standen von früheren Versuchen noch sehr dicke Dateien drin.
>> anscheinend wurden die nie wirklich ordentlich übertragen, und
>> dementsprechend startete diese Synchronisation immer wieder neu ...
>
> Weil davfs kein Wiederaufsetzen nach Verbindungsabbruch vorsieht?
> Der uebliche Protokoll-Design-Bug also :-}
>
> Einer der vielen Gruenden warum ich so einen Mist nicht verwende.
>

Und was verwendest du als Alternative?

Jan

[Ulli Horlacher]

https://fex.rus.uni-stuttgart.de/DOX/

[Diedrich Ehlerding]

Ulli Horlacher meinte:

>> > Weil davfs kein Wiederaufsetzen nach Verbindungsabbruch vorsieht?
>> > Der uebliche Protokoll-Design-Bug also :-}
>> >
>> > Einer der vielen Gruenden warum ich so einen Mist nicht verwende.
>> >
>>
>> Und was verwendest du als Alternative?
>
> https://fex.rus.uni-stuttgart.de/DOX/

Das setzt aber, wenn ichs richtig verstehe, einen FEX-fähigen Server
voraus und ist insoweit für meinen Fall unbrauchbar.

[Ulli Horlacher]

Diedrich Ehlerding <diedrich....@t-online.de> wrote:
> Ulli Horlacher meinte:
>
> >> > Weil davfs kein Wiederaufsetzen nach Verbindungsabbruch vorsieht?
> >> > Der uebliche Protokoll-Design-Bug also :-}
> >> >
> >> > Einer der vielen Gruenden warum ich so einen Mist nicht verwende.
> >> >
> >>
> >> Und was verwendest du als Alternative?
> >
> > https://fex.rus.uni-stuttgart.de/DOX/
>
> Das setzt aber, wenn ichs richtig verstehe, einen FEX-fähigen Server
> voraus und ist insoweit für meinen Fall unbrauchbar.

Ja. Deshalb schrieb ich auch oben von "ich".
Dass das keine Loesung fuer alle ist, haette ich dazuschreiben sollen.
Zumindest alle Hochschulangehoerige (und was sonst noch dem MWK
untersteht) in Baden-Wuerttemberg koennen https://fex.belwue.de
verwenden.

Dem DFN hatte ich es auch angeboten, aber die setzen lieber auf ihr
proprietaeres GigaMove: https://fex.belwue.de/fex-vs-bwsyncshare.html

[Arno Welzel]

Ulli Horlacher:

> Arno Welzel <use...@arnowelzel.de> wrote:
>> Ulli Horlacher:
>>
>>> Diedrich Ehlerding <diedrich....@t-online.de> wrote:
>>>
>>>> davfs hält allerlei Caches vor . Die werden bei Gelegenheit gesynct ...
>>>> und da standen von früheren Versuchen noch sehr dicke Dateien drin.
>>>> anscheinend wurden die nie wirklich ordentlich übertragen, und
>>>> dementsprechend startete diese Synchronisation immer wieder neu ...
>>>
>>> Weil davfs kein Wiederaufsetzen nach Verbindungsabbruch vorsieht?
>>> Der uebliche Protokoll-Design-Bug also :-}
>>
>> Das hat weniger mit dem Protokoll zu tun, als der Frage, wie mit dem
>> Ergebnis umgegangen werden soll.
>>
>> Wenn man eien Datei sendet und die Übertragung von 30% abbricht, sind im
>> Ziel nur 30% der Datei vorhanden. Da die Operation "Datei senden" aber
>> atomar sein muss, kann man im Ziel nicht einfach mal diese 30% liegen
>> lassen und hoffen, dass irgendwann mal der Rest nachgereicht wird und
>> die Datei bis dahin ewig liegen lassen.
>
> Ein vernuenftiges Protokoll mit vernuenftiger Implementierung
> beruecksichtigt das. Sonst waere WAN-Transfer im Multi-TB Bereich kaum
> moeglich.

Welches Protokoll implementiert die automatische Bereinigung von nur
teilweise übertragenen Dateien, bei denen nach dem Abbruch nie ein
erneuter Versuch zur Übertragung des noch fehlenden Teils kommt?

rsync macht das schon mal nicht - wenn das abbricht, bleiben die Reste
halt ewig stehen.

>>> Einer der vielen Gruenden warum ich so einen Mist nicht verwende.
>>
>> Die Alternative beim OP wäre halt gewesen, dass er jetzt etliche
>> Fragmente unvollständig hochgeladener Dateien auf dem Server hätte und
>> diese manuell aufräumen muss, wenn er sie nicht wirklich übertragen will.
>
> Bei einem vernuenftigen Protokoll mit vernuenftiger Implementierung
> passiert das automatisch.

Welche machen das?

[Arno Welzel]

Ulli Horlacher:

> Diedrich Ehlerding <diedrich....@t-online.de> wrote:
>> Ulli Horlacher meinte:
>>
>>>>> Weil davfs kein Wiederaufsetzen nach Verbindungsabbruch vorsieht?
>>>>> Der uebliche Protokoll-Design-Bug also :-}
>>>>>
>>>>> Einer der vielen Gruenden warum ich so einen Mist nicht verwende.
>>>>>
>>>>
>>>> Und was verwendest du als Alternative?
>>>
>>> https://fex.rus.uni-stuttgart.de/DOX/
>>
>> Das setzt aber, wenn ichs richtig verstehe, einen FEX-fähigen Server
>> voraus und ist insoweit für meinen Fall unbrauchbar.
>
> Ja. Deshalb schrieb ich auch oben von "ich".
> Dass das keine Loesung fuer alle ist, haette ich dazuschreiben sollen.
> Zumindest alle Hochschulangehoerige (und was sonst noch dem MWK
> untersteht) in Baden-Wuerttemberg koennen https://fex.belwue.de
> verwenden.

Und was passiert bei F*EX, wenn man eine Datei vom Server herunterlädt
und der Download abbricht? Wer räumt dann die teilweise heruntergeladene
Datei auf, wenn der Download nie fortgesetzt wird?

[Arno Welzel]

Diedrich Ehlerding:

> Ulli Horlacher meinte:
>
>>>> Weil davfs kein Wiederaufsetzen nach Verbindungsabbruch vorsieht?
>>>> Der uebliche Protokoll-Design-Bug also :-}
>>>>
>>>> Einer der vielen Gruenden warum ich so einen Mist nicht verwende.
>>>>
>>>
>>> Und was verwendest du als Alternative?
>>
>> https://fex.rus.uni-stuttgart.de/DOX/
>
> Das setzt aber, wenn ichs richtig verstehe, einen FEX-fähigen Server
> voraus und ist insoweit für meinen Fall unbrauchbar.

Jede Lösung, die das Fortsetzen von Dateiübertragungen unterstützen
soll, muss einen Server haben, der dem Client mitteilt, ob eine Datei
bereits vorhanden ist und welche Teil davon bereits vorliegt.

F*EX ist eine Lösung aber es geht auch rsync oder sftp mit
"reput"-Kommando - setzt aber alles einen geeigneten Server voraus.

[Ulli Horlacher]

Arno Welzel <use...@arnowelzel.de> wrote:

> > Ein vernuenftiges Protokoll mit vernuenftiger Implementierung
> > beruecksichtigt das. Sonst waere WAN-Transfer im Multi-TB Bereich kaum
> > moeglich.
>
> Welches Protokoll implementiert die automatische Bereinigung von nur
> teilweise übertragenen Dateien, bei denen nach dem Abbruch nie ein
> erneuter Versuch zur Übertragung des noch fehlenden Teils kommt?

Hatte ich zuvor geschrieben: F*EX

> rsync macht das schon mal nicht - wenn das abbricht, bleiben die Reste
> halt ewig stehen.

Das ist auch ungeeignet um Dritten Dateien zukommen zu lassen.

> > Bei einem vernuenftigen Protokoll mit vernuenftiger Implementierung
> > passiert das automatisch.
>
> Welche machen das?

F*EX.
Ich hatte dir einen Account gegeben, aber du hattest wohl kein Interesse.

[Ulli Horlacher]

Arno Welzel <use...@arnowelzel.de> wrote:

> >>> https://fex.rus.uni-stuttgart.de/DOX/
> >>
> >> Das setzt aber, wenn ichs richtig verstehe, einen FEX-fähigen Server
> >> voraus und ist insoweit für meinen Fall unbrauchbar.
> >
> > Ja. Deshalb schrieb ich auch oben von "ich".
> > Dass das keine Loesung fuer alle ist, haette ich dazuschreiben sollen.
> > Zumindest alle Hochschulangehoerige (und was sonst noch dem MWK
> > untersteht) in Baden-Wuerttemberg koennen https://fex.belwue.de
> > verwenden.
>
> Und was passiert bei F*EX, wenn man eine Datei vom Server herunterlädt
> und der Download abbricht? Wer räumt dann die teilweise heruntergeladene
> Datei auf, wenn der Download nie fortgesetzt wird?

Der fexserver bzw dessen "cleaning woman" cleanup.
Oder meinst du auf Client-Seite?
Da haengt es vom eingesetzten Client-Programm ab.
Ein Webbrowser wird es wohl liegen lassen.

[Ulli Horlacher]

Arno Welzel <use...@arnowelzel.de> wrote:

> F*EX ist eine Lösung aber es geht auch rsync oder sftp mit
> "reput"-Kommando - setzt aber alles einen geeigneten Server voraus.

Welcher rsync Server kann "reput"?

[Arno Welzel]

Ulli Horlacher:

> Arno Welzel <use...@arnowelzel.de> wrote:
>
>>> Ein vernuenftiges Protokoll mit vernuenftiger Implementierung
>>> beruecksichtigt das. Sonst waere WAN-Transfer im Multi-TB Bereich kaum
>>> moeglich.
>>
>> Welches Protokoll implementiert die automatische Bereinigung von nur
>> teilweise übertragenen Dateien, bei denen nach dem Abbruch nie ein
>> erneuter Versuch zur Übertragung des noch fehlenden Teils kommt?
>
> Hatte ich zuvor geschrieben: F*EX

Auch auf dem Client?

Also wenn ein Client mit F*EX eine 100 GB Datei vom Server herunterladen
will und nach 2 GB die Übertragung abbricht, wird dann die lokal
vorhandenen 2 GB große Datei automatisch gelöscht nach eine
einstellbaren Zeit, wenn der Benutzer sich entscheidet, die Übertragung
nie fortzusetzen? Habe ich den dafür zu installierenden lokalen Dienst
und die Einstellmöglichkeiten irgendwo übersehen?

>>> Bei einem vernuenftigen Protokoll mit vernuenftiger Implementierung
>>> passiert das automatisch.
>>
>> Welche machen das?
>
> F*EX.
> Ich hatte dir einen Account gegeben, aber du hattest wohl kein Interesse.

Nein, bisher keinen Bedarf. Ich habe genügend andere Server, die ich für
Dateiweitergabe nutzen kann - ja, auch mit Dateigrößen jenseits 100 GB.

[Arno Welzel]

Ulli Horlacher:

> Arno Welzel <use...@arnowelzel.de> wrote:
>
>>>>> https://fex.rus.uni-stuttgart.de/DOX/
>>>>
>>>> Das setzt aber, wenn ichs richtig verstehe, einen FEX-fähigen Server
>>>> voraus und ist insoweit für meinen Fall unbrauchbar.
>>>
>>> Ja. Deshalb schrieb ich auch oben von "ich".
>>> Dass das keine Loesung fuer alle ist, haette ich dazuschreiben sollen.
>>> Zumindest alle Hochschulangehoerige (und was sonst noch dem MWK
>>> untersteht) in Baden-Wuerttemberg koennen https://fex.belwue.de
>>> verwenden.
>>
>> Und was passiert bei F*EX, wenn man eine Datei vom Server herunterlädt
>> und der Download abbricht? Wer räumt dann die teilweise heruntergeladene
>> Datei auf, wenn der Download nie fortgesetzt wird?
>
> Der fexserver bzw dessen "cleaning woman" cleanup.
> Oder meinst du auf Client-Seite?

Ja, die Client-Seite.

> Da haengt es vom eingesetzten Client-Programm ab.

Warum? Ich dachte, dass sei Aufgabe des Protokolls? ;-)

> Ein Webbrowser wird es wohl liegen lassen.

fexget ebenfalls.

[Arno Welzel]

Ulli Horlacher:

> Arno Welzel <use...@arnowelzel.de> wrote:
>
>> F*EX ist eine Lösung aber es geht auch rsync oder sftp mit
>> "reput"-Kommando - setzt aber alles einen geeigneten Server voraus.
>
> Welcher rsync Server kann "reput"?

Wieso rsync? Ich sprach von "sftp mit reput".

[Ulli Horlacher]

Arno Welzel <use...@arnowelzel.de> wrote:
> Ulli Horlacher:
>
> > Arno Welzel <use...@arnowelzel.de> wrote:
> >
> >>> Ein vernuenftiges Protokoll mit vernuenftiger Implementierung
> >>> beruecksichtigt das. Sonst waere WAN-Transfer im Multi-TB Bereich kaum
> >>> moeglich.
> >>
> >> Welches Protokoll implementiert die automatische Bereinigung von nur
> >> teilweise übertragenen Dateien, bei denen nach dem Abbruch nie ein
> >> erneuter Versuch zur Übertragung des noch fehlenden Teils kommt?
> >
> > Hatte ich zuvor geschrieben: F*EX
>
> Auch auf dem Client?

Auf dem Server.

> Also wenn ein Client mit F*EX eine 100 GB Datei vom Server herunterladen
> will und nach 2 GB die Übertragung abbricht, wird dann die lokal
> vorhandenen 2 GB große Datei automatisch gelöscht nach eine
> einstellbaren Zeit, wenn der Benutzer sich entscheidet, die Übertragung
> nie fortzusetzen? Habe ich den dafür zu installierenden lokalen Dienst
> und die Einstellmöglichkeiten irgendwo übersehen?

Ist nicht notwendig, da die F*EX Clients automatisch wiederaufsetzen.

[Ulli Horlacher]

Arno Welzel <use...@arnowelzel.de> wrote:

> > Da haengt es vom eingesetzten Client-Programm ab.
>
> Warum? Ich dachte, dass sei Aufgabe des Protokolls? ;-)

Man muss es halt auch sauber implementieren.

> > Ein Webbrowser wird es wohl liegen lassen.
>
> fexget ebenfalls.

Das versucht die Datei so lange herunterzuladen, bis sie vollstaendig ist.

[Ulli Horlacher]

Arno Welzel <use...@arnowelzel.de> wrote:
> Ulli Horlacher:
>
> > Arno Welzel <use...@arnowelzel.de> wrote:
> >
> >> F*EX ist eine Lösung aber es geht auch rsync oder sftp mit
> >> "reput"-Kommando - setzt aber alles einen geeigneten Server voraus.
> >
> > Welcher rsync Server kann "reput"?
>
> Wieso rsync? Ich sprach von "sftp mit reput".

Somit ist rsync keine Loesung. Das faengt wie Sisyphus immer wieder von
vorne an.

[Arno Welzel]

Ulli Horlacher:

> Arno Welzel <use...@arnowelzel.de> wrote:

[...]

>> Also wenn ein Client mit F*EX eine 100 GB Datei vom Server herunterladen
>> will und nach 2 GB die Übertragung abbricht, wird dann die lokal
>> vorhandenen 2 GB große Datei automatisch gelöscht nach eine
>> einstellbaren Zeit, wenn der Benutzer sich entscheidet, die Übertragung
>> nie fortzusetzen? Habe ich den dafür zu installierenden lokalen Dienst
>> und die Einstellmöglichkeiten irgendwo übersehen?
>
> Ist nicht notwendig, da die F*EX Clients automatisch wiederaufsetzen.

Mir ging es geht aber gerade darum, was passiert, wenn man *nicht*
fortfährt mit dem Download. Dafür kann es ja auch Gründe geben.

Oder wird fexget nach deinem Logout/Login automatisch gestartet, nur
weil man es vorher schon mal benutzt hatte und noch ein unvollständiger
Download ansteht? Wohl eher nicht.

[Arno Welzel]

Ulli Horlacher:

> Arno Welzel <use...@arnowelzel.de> wrote:
>
>>> Da haengt es vom eingesetzten Client-Programm ab.
>>
>> Warum? Ich dachte, dass sei Aufgabe des Protokolls? ;-)
>
> Man muss es halt auch sauber implementieren.
>
>
>>> Ein Webbrowser wird es wohl liegen lassen.
>>
>> fexget ebenfalls.
>
> Das versucht die Datei so lange herunterzuladen, bis sie vollstaendig ist.

Und wenn fexget vor dem Ende des Downloads beendet wird, dann eben
nicht. Dann muss man fexget mit den selben Parametern nämlich nochmal
starten.

[Arno Welzel]

Ulli Horlacher:

> Arno Welzel <use...@arnowelzel.de> wrote:
>> Ulli Horlacher:
>>
>>> Arno Welzel <use...@arnowelzel.de> wrote:
>>>
>>>> F*EX ist eine Lösung aber es geht auch rsync oder sftp mit
>>>> "reput"-Kommando - setzt aber alles einen geeigneten Server voraus.
>>>
>>> Welcher rsync Server kann "reput"?
>>
>> Wieso rsync? Ich sprach von "sftp mit reput".
>
> Somit ist rsync keine Loesung. Das faengt wie Sisyphus immer wieder von
> vorne an.

Nein, wieso? Wenn Du von einer 100 GB großen Datei nur 1 MB ändest,
überträgt rsync auch nur diesen Teil und nicht jedesmal 100 GB.

[Ulli Horlacher]

Wenn du es explizit abbrichst, startet es nicht von alleine wieder.

[Arno Welzel]

Ulli Horlacher:

> Arno Welzel <use...@arnowelzel.de> wrote:
>> Ulli Horlacher:
>>
>>> Arno Welzel <use...@arnowelzel.de> wrote:
>> [...]
>>>> Also wenn ein Client mit F*EX eine 100 GB Datei vom Server herunterladen
>>>> will und nach 2 GB die Übertragung abbricht, wird dann die lokal
>>>> vorhandenen 2 GB große Datei automatisch gelöscht nach eine
>>>> einstellbaren Zeit, wenn der Benutzer sich entscheidet, die Übertragung
>>>> nie fortzusetzen? Habe ich den dafür zu installierenden lokalen Dienst
>>>> und die Einstellmöglichkeiten irgendwo übersehen?
>>>
>>> Ist nicht notwendig, da die F*EX Clients automatisch wiederaufsetzen.
>>
>> Mir ging es geht aber gerade darum, was passiert, wenn man *nicht*
>> fortfährt mit dem Download. Dafür kann es ja auch Gründe geben.
>>
>> Oder wird fexget nach deinem Logout/Login automatisch gestartet, nur
>> weil man es vorher schon mal benutzt hatte und noch ein unvollständiger
>> Download ansteht? Wohl eher nicht.
>
> Wenn du es explizit abbrichst, startet es nicht von alleine wieder.

Der Abbruch muss nicht explizit passieren - auch Stromausfall etc. kann
vorkommen. Ebenso, dass der Server beendet und die Datei auf dem Server
gelöscht wird, bevor sie vollständig übertragen wurde. Alles Fälle, die
selten vorkommen in der Praxis, aber eben nicht grundsätzlich unmöglich
sind.

Worum es mir konkret ging: das automatische Aufräumen von teilweise
übertragenen Dateien erfordert zwangsläufig einen Dienst, der das auch
tut. Auf dem Server ist das natürlich keine Kunst. Aber ein reines
Kommandozeilentool wie fexget macht sowas logischerweise nicht.

Und nur der Vollständigkeit halber: abgebrochene Übertragungen
fortsetzen kann (S)FTP auch schon lange. Selbst HTTP und damit auch
WebDAV kennt so einen Mechanismus grundsätzlich, allerdings nur in einer
Richtung für Downloads, nicht für Uploads.

[Ulli Horlacher]

Arno Welzel <use...@arnowelzel.de> wrote:

> Nein, wieso? Wenn Du von einer 100 GB großen Datei nur 1 MB ändest,
> überträgt rsync auch nur diesen Teil und nicht jedesmal 100 GB.

Ich hab nur --append gefunden.
Wie kann rsync also zB eine modifiziertes VM image delta uebertragen?

Davon abgesehen funktioniert das nur, wenn man auf beiden Seiten einen
Account hat und beide hosts eine direkte tcp Verbindung zu lassen.
Bei NAT und/oder firewall funktioniert rsync nicht.

[Arno Welzel]

Ulli Horlacher:

> Arno Welzel <use...@arnowelzel.de> wrote:
>
>> Nein, wieso? Wenn Du von einer 100 GB großen Datei nur 1 MB ändest,
>> überträgt rsync auch nur diesen Teil und nicht jedesmal 100 GB.
>
> Ich hab nur --append gefunden.
> Wie kann rsync also zB eine modifiziertes VM image delta uebertragen?

Das tut es automatisch, wenn man es nicht explizit mit --whole-file
anders angibt. Ansonsten kann mit mit --block-size angeben, wie groß die
Blöcke sein sollen, die rsync für Änderungen prüfen soll.

Siehe auch: <https://download.samba.org/pub/rsync/rsync.html>

Zitat:

"Rsync is a fast and extraordinarily versatile file copying tool. It can
copy locally, to/from another host over any remote shell, or to/from a
remote rsync daemon. It offers a large number of options that control
every aspect of its behavior and permit very flexible specification of
the set of files to be copied. It is famous for its delta-transfer
algorithm, which reduces the amount of data sent over the network by
sending only the differences between the source files and the existing
files in the destination. Rsync is widely used for backups and mirroring
and as an improved copy command for everyday use."

> Davon abgesehen funktioniert das nur, wenn man auf beiden Seiten einen
> Account hat und beide hosts eine direkte tcp Verbindung zu lassen.

Nein, es genügt eine Seite.

> Bei NAT und/oder firewall funktioniert rsync nicht.

Hier schon. Eine Seite ist ein Linux-Server, die andere Seite bei mir
ist eine Linux-Kiste hinter einem DSL-Router mit NAT. Das Ganze wird
dann noch durch SSH getunnelt - dafür ist natürlich ein Account auf dem
Server nötig, klar. Zu anderen Servern habe ich ein VPN via IPSec, was
auch durch NAT durchgeht. Das ist auch für die meisten Endbenutzer nicht
unbedingt praktikabel - aber mir ging es nur um das generelle Prinzip,
wie rsync arbeitet.

[Laurenz Trossel]

On 2022-07-11, Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:

> Davon abgesehen funktioniert das nur, wenn man auf beiden Seiten einen
> Account hat und beide hosts eine direkte tcp Verbindung zu lassen.
> Bei NAT und/oder firewall funktioniert rsync nicht.

Nein, nötig ist nur ein Stream zwischen den beiden rsync-Prozessen. Dafür
eine direkte SSH-Verbindung zu nutzen, ist der übliche Weg aber nicht der
Einzige. Du kannst die Verbindung auch durch 7 Proxies ziehen.

[Ulli Horlacher]

Arno Welzel <use...@arnowelzel.de> wrote:
> Ulli Horlacher:
>
> > Arno Welzel <use...@arnowelzel.de> wrote:
> >
> >> Nein, wieso? Wenn Du von einer 100 GB großen Datei nur 1 MB ändest,
> >> überträgt rsync auch nur diesen Teil und nicht jedesmal 100 GB.
> >
> > Ich hab nur --append gefunden.
> > Wie kann rsync also zB eine modifiziertes VM image delta uebertragen?
>
> Das tut es automatisch, wenn man es nicht explizit mit --whole-file
> anders angibt. Ansonsten kann mit mit --block-size angeben, wie groß die
> Blöcke sein sollen, die rsync für Änderungen prüfen soll.

Funktioniert nicht:

framstag@juhu:/tmp: l zz*
-RW- 1,148,568,642 2022-07-11 12:06 zz1

framstag@juhu:/tmp: rsync -v --bwlimit=100m zz1 zz2
zz1

sent 1,148,849,129 bytes received 35 bytes 99,899,927.30 bytes/sec
total size is 1,148,568,642 speedup is 1.00


framstag@juhu:/tmp: cp zz1 zz3
framstag@juhu:/tmp: vi zz3
framstag@juhu:/tmp: diff -u zz1 zz3
--- zz1 2022-07-11 12:06:28.798192481 +0200
+++ zz3 2022-07-11 12:16:41.336387958 +0200
@@ -1,4 +1,4 @@
-#############################################################################
+...##########################################################################
#############################################################################
#############################################################################
#############################################################################


framstag@juhu:/tmp: l zz*
-RW- 1,148,568,642 2022-07-11 12:06 zz1
-RW- 1,148,568,642 2022-07-11 12:15 zz2
-RW- 1,148,568,642 2022-07-11 12:16 zz3


framstag@juhu:/tmp: rsync -v --bwlimit=100m zz3 zz2
zz3

sent 1,148,849,159 bytes received 35 bytes 99,899,929.91 bytes/sec
total size is 1,148,568,672 speedup is 1.00

framstag@juhu:/tmp: l zz*
-RW- 1,148,568,642 2022-07-11 12:06 zz1
-RW- 1,148,568,642 2022-07-11 12:17 zz2
-RW- 1,148,568,642 2022-07-11 12:16 zz3

Es wird also nach Aenderung von wenigen Bytes das gesamte file uebertragen
und kein delta.

> > Davon abgesehen funktioniert das nur, wenn man auf beiden Seiten einen
> > Account hat und beide hosts eine direkte tcp Verbindung zu lassen.
>
> Nein, es genügt eine Seite.

Wie kopierst du was, wenn du vom Ziel keinen Account hast?
Wie willst du mir also was schicken?

> > Bei NAT und/oder firewall funktioniert rsync nicht.
>
> Hier schon. Eine Seite ist ein Linux-Server, die andere Seite bei mir
> ist eine Linux-Kiste hinter einem DSL-Router mit NAT. Das Ganze wird
> dann noch durch SSH getunnelt - dafür ist natürlich ein Account auf dem
> Server nötig, klar. Zu anderen Servern habe ich ein VPN via IPSec, was
> auch durch NAT durchgeht.

Das ist fuer rsync eine direkte Verbindung.
Das ist aufwaendig umzusetzen.
Bei F*EX brauchst du das alles nicht.

[Laurenz Trossel]

On 2022-07-11, Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:

> Funktioniert nicht:

Manpages liest also auch nicht.

[--whole-file] is the default when both the source and destination are
specified as local paths.

Was für einen Sinn würde es machen, wenn rsync beide lokale Dateien
blockweise liest und hasht, um dann nur die geänderten Bytes aus der einen
Datei zu lesen und alles andere aus der anderen Datei?

> Bei F*EX brauchst du das alles nicht.

Du kennst dich mit rsync nicht aus. Das macht ja nichts. Es will dir
niemand FEX ausreden.

[Marco Moock]

Am Mon, 11 Jul 2022 11:22:58 +0200
schrieb Arno Welzel <use...@arnowelzel.de>:

> Das Ganze wird dann noch durch SSH getunnelt - dafür ist natürlich
> ein Account auf dem Server nötig, klar. Zu anderen Servern habe ich
> ein VPN via IPSec, was auch durch NAT durchgeht. Das ist auch für die
> meisten Endbenutzer nicht unbedingt praktikabel - aber mir ging es
> nur um das generelle Prinzip, wie rsync arbeitet.

Dann hast du einen Tunnel, der sich so verhält als gäbe es kein NAT.

[Arno Welzel]

Ulli Horlacher:

> Arno Welzel <use...@arnowelzel.de> wrote:
>> Ulli Horlacher:
>>
>>> Arno Welzel <use...@arnowelzel.de> wrote:
>>>
>>>> Nein, wieso? Wenn Du von einer 100 GB großen Datei nur 1 MB ändest,
>>>> überträgt rsync auch nur diesen Teil und nicht jedesmal 100 GB.
>>>
>>> Ich hab nur --append gefunden.
>>> Wie kann rsync also zB eine modifiziertes VM image delta uebertragen?
>>
>> Das tut es automatisch, wenn man es nicht explizit mit --whole-file
>> anders angibt. Ansonsten kann mit mit --block-size angeben, wie groß die
>> Blöcke sein sollen, die rsync für Änderungen prüfen soll.
>
> Funktioniert nicht:
>
> framstag@juhu:/tmp: l zz*
> -RW- 1,148,568,642 2022-07-11 12:06 zz1
>
> framstag@juhu:/tmp: rsync -v --bwlimit=100m zz1 zz2
> zz1
>
> sent 1,148,849,129 bytes received 35 bytes 99,899,927.30 bytes/sec
> total size is 1,148,568,642 speedup is 1.00

> Es wird also nach Aenderung von wenigen Bytes das gesamte file uebertragen
> und kein delta.

Ja - siehe Doku.

>>> Davon abgesehen funktioniert das nur, wenn man auf beiden Seiten einen
>>> Account hat und beide hosts eine direkte tcp Verbindung zu lassen.
>>
>> Nein, es genügt eine Seite.
>
> Wie kopierst du was, wenn du vom Ziel keinen Account hast?
> Wie willst du mir also was schicken?

Gar nicht. Darum ging es auch nicht, sondern um die Frage, wie rsync mit
einem *Servrer* arbeitet.

>>> Bei NAT und/oder firewall funktioniert rsync nicht.
>>
>> Hier schon. Eine Seite ist ein Linux-Server, die andere Seite bei mir
>> ist eine Linux-Kiste hinter einem DSL-Router mit NAT. Das Ganze wird
>> dann noch durch SSH getunnelt - dafür ist natürlich ein Account auf dem
>> Server nötig, klar. Zu anderen Servern habe ich ein VPN via IPSec, was
>> auch durch NAT durchgeht.
>
> Das ist fuer rsync eine direkte Verbindung.
> Das ist aufwaendig umzusetzen.

Für mich nicht.

> Bei F*EX brauchst du das alles nicht.

Ich will auch nicht rsync statt F*EX nutzen, sondern habe nur erklärt,
wie rsync funktioniert.

JFTR: via HTTP kann ich auch zu meinem Nextcloud-Server 100 GB große
Dateien *im* *Browser* senden. Wir leben im Jahr 2022 - Dateiuploads
ausschließlich mit Formular und <input type="file"> sind schon lange
nicht mehr üblich.

[Arno Welzel]

Marco Moock:

Ja. Und?

[Ulli Horlacher]

Arno Welzel <use...@arnowelzel.de> wrote:
> Ulli Horlacher:
>
> > Arno Welzel <use...@arnowelzel.de> wrote:
> >> Ulli Horlacher:
> >>
> >>> Arno Welzel <use...@arnowelzel.de> wrote:
> >>>
> >>>> Nein, wieso? Wenn Du von einer 100 GB großen Datei nur 1 MB ändest,
> >>>> überträgt rsync auch nur diesen Teil und nicht jedesmal 100 GB.
> >>>
> >>> Ich hab nur --append gefunden.
> >>> Wie kann rsync also zB eine modifiziertes VM image delta uebertragen?
> >>
> >> Das tut es automatisch, wenn man es nicht explizit mit --whole-file
> >> anders angibt. Ansonsten kann mit mit --block-size angeben, wie groß die
> >> Blöcke sein sollen, die rsync für Änderungen prüfen soll.
> >
> > Funktioniert nicht:
> >
> > framstag@juhu:/tmp: l zz*
> > -RW- 1,148,568,642 2022-07-11 12:06 zz1
> >
> > framstag@juhu:/tmp: rsync -v --bwlimit=100m zz1 zz2
> > zz1
> >
> > sent 1,148,849,129 bytes received 35 bytes 99,899,927.30 bytes/sec
> > total size is 1,148,568,642 speedup is 1.00
> > Es wird also nach Aenderung von wenigen Bytes das gesamte file uebertragen
> > und kein delta.
>
> Ja - siehe Doku.

Warum behauptest du dann das Gegenteil (erstes Zitat oben!)?

> >>> Davon abgesehen funktioniert das nur, wenn man auf beiden Seiten einen
> >>> Account hat und beide hosts eine direkte tcp Verbindung zu lassen.
> >>
> >> Nein, es genügt eine Seite.
> >
> > Wie kopierst du was, wenn du vom Ziel keinen Account hast?
> > Wie willst du mir also was schicken?
>
> Gar nicht. Darum ging es auch nicht, sondern um die Frage, wie rsync mit
> einem *Servrer* arbeitet.

Du brauchst da dann aber einen UNIX Account.

> >>> Bei NAT und/oder firewall funktioniert rsync nicht.
> >>
> >> Hier schon. Eine Seite ist ein Linux-Server, die andere Seite bei mir
> >> ist eine Linux-Kiste hinter einem DSL-Router mit NAT. Das Ganze wird
> >> dann noch durch SSH getunnelt - dafür ist natürlich ein Account auf dem
> >> Server nötig, klar. Zu anderen Servern habe ich ein VPN via IPSec, was
> >> auch durch NAT durchgeht.
> >
> > Das ist fuer rsync eine direkte Verbindung.
> > Das ist aufwaendig umzusetzen.
>
> Für mich nicht.

Fuer 99.9% aller User aber schon.

> JFTR: via HTTP kann ich auch zu meinem Nextcloud-Server 100 GB große
> Dateien *im* *Browser* senden. Wir leben im Jahr 2022 - Dateiuploads
> ausschließlich mit Formular und <input type="file"> sind schon lange
> nicht mehr üblich.

Wie machst du dann?
Mit websockets?

[Arno Welzel]

Ulli Horlacher:

> Arno Welzel <use...@arnowelzel.de> wrote:
>> Ulli Horlacher:
>>
>>> Arno Welzel <use...@arnowelzel.de> wrote:
>>>> Ulli Horlacher:
>>>>
>>>>> Arno Welzel <use...@arnowelzel.de> wrote:
>>>>>
>>>>>> Nein, wieso? Wenn Du von einer 100 GB großen Datei nur 1 MB ändest,
>>>>>> überträgt rsync auch nur diesen Teil und nicht jedesmal 100 GB.

[...]

>>> sent 1,148,849,129 bytes received 35 bytes 99,899,927.30 bytes/sec
>>> total size is 1,148,568,642 speedup is 1.00
>>> Es wird also nach Aenderung von wenigen Bytes das gesamte file uebertragen
>>> und kein delta.
>>
>> Ja - siehe Doku.
>
> Warum behauptest du dann das Gegenteil (erstes Zitat oben!)?

Gegenteil wovon?

Ich spreche die ganze Zeit nur vom Kontext, dass man einen *Server* hat
und einen *Client*. Oder nutzt Du fexget und fexsend auch, um lokal von
einer Datei in einer andere zu kopieren? Wohl eher nicht.

Dass rsync auch bei rein lokalen Dateikopien ebenfalls nur Deltas
überträgt, habe ich nicht behauptet. Das ergäbe auch absolut keinen
Sinn, da ja in jedem Fall die komplette Quell- und Zieldatei gelesen
werden muss, um festzustellen, welche Änderungen vorhanden sind. Das
würde länger dauern, als die Quelldatei einfach in das Ziel zu kopieren.

Deshalb gilt auch - siehe Doku:

-W, --whole-file

With this option rsync's delta-transfer algorithm is not used and the
whole file is sent as-is instead.
(...)
This is the default when both the source and destination are specified
as local paths.

(Zitat Ende)

Wenn man aber rsync als *Client* mit einem *Server* macht, so dass auf
beiden Seiten jeweils ein rsync-Prozess läuft und diese miteinaner über
eine Netzverbindung reden, wird standardmäßig nur blockweise das
übertragen, was sich zwischen Quelle und Ziel unterscheidet. Die dabei
benutzte Blockgröße zur Prüfung ist konfigurierbar - siehe Doku.

Den Rest darfst Du gerne selber recherchieren, wenn es Dich interessiert.

[...]

>> Gar nicht. Darum ging es auch nicht, sondern um die Frage, wie rsync mit
>> einem *Servrer* arbeitet.
>
> Du brauchst da dann aber einen UNIX Account.

Korrekt. Deswegen habe ich auch nicht behauptet, dass man rsync statt
F*EX nutzen *soll*, sondern es nur als eine generell Option für
Dateiübertragung genannt. Ob diese Option im Einzefall sinnvoll ist,
hängt vom Einzelfall ab. Auch F*EX hat konkrete Anwendungsfälle.

Ich nutze rsync z.B. regelmäßig, um Daten von diversen Servern zentral
zu sammeln, ohne dass ich dafür jedesmal alle Dateien vollständig
übertragen muss. Die Dateien, die ich schon habe, sendet rsync nicht
nochmal und bei größeren Dateien werden nur die Änderungen übermittelt.
Weiterhin brauche ich am Ziel, wo die Daten gesammelt werden, keinen
Serverdienst sondern nur eine Shell mit rsync und SSH.

[...]

>> JFTR: via HTTP kann ich auch zu meinem Nextcloud-Server 100 GB große
>> Dateien *im* *Browser* senden. Wir leben im Jahr 2022 - Dateiuploads
>> ausschließlich mit Formular und <input type="file"> sind schon lange
>> nicht mehr üblich.
>
> Wie machst du dann?
> Mit websockets?

Die übliche Technik dazu ist XHR (aka "AJAX") - also einfach simple
HTTP-Requests, wo die Dateien in kleinen Portionen von z.B. 1 MB
gesendet werden. Websockets sind dazu nicht notwendig, nur JavaScript.
XHR kann man als gegeben annehmen - es gibt keine Browser, die das nicht
beherrschen. Selbst der Internet Explorer 6 konnte das schon.

Und nein, auch das will ich nicht als ultimative Lösung gegenüber F*EX
anpreisen, sondern erwähne das nur informativ - schon deshalb, weil
zumindest bisher das Wiederaufnahmen von Teil-Uploads nicht vorgesehen ist.

Die Zielgruppe von Nextcloud sind eher Leute, die einfach Dokumente,
Bilder etc. weitergeben möchten und dazu keine separaten Tools benutzen
wollen, sondern das im Browser tun können. Wenn da mal ein Upload 10
Minuten dauert, ist das in der Regel kein Problem - und ich spreche aus
der Erfahrung mit aktuell etwa 120 Personen, die sowas nutzen und für
die ich der Ansprechpartner bin, wenn etwas nicht klappt.

Auch kollaboratives Office für Textverarbeitung oder Tabellenkalkulation
im Browser ist damit möglich und funktioniert erstaunlich gut - man kann
gut gleichzeitig mit mehreren Personen an einer Datei arbeiten und sieht
in Echtzeit, was die Anderen gerade darin tun - ganz ohne Google Docs
oder Microsoft 365.

[Thomas Dorner]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> writes:
> Arno Welzel <use...@arnowelzel.de> wrote:
>> Ulli Horlacher:
>>
>> > Arno Welzel <use...@arnowelzel.de> wrote:
>> >> Ulli Horlacher:
>> >>
>> >>> Arno Welzel <use...@arnowelzel.de> wrote:
>> >>>
>> >>>> Nein, wieso? Wenn Du von einer 100 GB großen Datei nur 1 MB ändest,
>> >>>> überträgt rsync auch nur diesen Teil und nicht jedesmal 100 GB.
>> >>>
>> >>> Ich hab nur --append gefunden.
>> >>> Wie kann rsync also zB eine modifiziertes VM image delta uebertragen?
>> >>
>> >> Das tut es automatisch, wenn man es nicht explizit mit --whole-file
>> >> anders angibt. Ansonsten kann mit mit --block-size angeben, wie groß die
>> >> Blöcke sein sollen, die rsync für Änderungen prüfen soll.
>> >
>> > Funktioniert nicht:
>> >
>> > framstag@juhu:/tmp: l zz*
>> > -RW- 1,148,568,642 2022-07-11 12:06 zz1
>> >
>> > framstag@juhu:/tmp: rsync -v --bwlimit=100m zz1 zz2
>> > zz1
>> >
>> > sent 1,148,849,129 bytes received 35 bytes 99,899,927.30 bytes/sec
>> > total size is 1,148,568,642 speedup is 1.00
>> > Es wird also nach Aenderung von wenigen Bytes das gesamte file uebertragen
>> > und kein delta.
>>
>> Ja - siehe Doku.
>
> Warum behauptest du dann das Gegenteil (erstes Zitat oben!)?

Aus dem gleichen Post:

| [...] It is famous for its delta-transfer

|algorithm, which reduces the amount of data sent over the network by

^^^^^^^^^^^^^^^^^^^^^

|sending only the differences between the source files and the existing

|files in the destination. [...]

Und wie andere schon erwähnt haben, ist das geänderte lokale Verhalten
klar dokumentiert.

>> > Das ist fuer rsync eine direkte Verbindung.
>> > Das ist aufwaendig umzusetzen.

rsync nutzt SSH als Default, damit ist das ganz einfach.

Viele Grüße, Thomas
--
Adresse gilt nur kurzzeitig!

[Markus Franzke]

Am 07.07.22 um 14:57 schrieb Arno Welzel:

>
> rsync macht das schon mal nicht - wenn das abbricht, bleiben die Reste
> halt ewig stehen.
>

Wenn man --partial verwendet. Sonst wird unvollständiger Müll entsorgt.
Zumindst bei mir.

M

[Arno Welzel]

Markus Franzke:

Kann ich nicht bestätigen. Wenn der rsync-Prozess abgebrochen wird, wird
da nichts augeräumt - wie auch?

[Markus Franzke]

Am 13.07.22 um 20:55 schrieb Arno Welzel:

Gerade ausprobiert:

--

rsync grosse_datei remote:/data

Auf remote wächst eine .grosse_datei.UKrYpK

Ctrl-C

Auf remote ist die Datei verschwunden

--

rsync --partial grosse_datei remote:/data

Auf remote wächst eine .grosse_datei.xyzABC

Ctrl-C

Auf remote befindet sich die Datei /data/grosse_datei deutlich kleiner
als das Original

--

Kommt wahrscheinlich auf die Art des 'Abbruchs' an, ob irgendein
atexit() noch aufräumen kann.

rsync : version 3.2.3 protocol version 31 (beiderseits)

M

[Arno Welzel]

Markus Franzke:

> Am 13.07.22 um 20:55 schrieb Arno Welzel:
>> Markus Franzke:
>>
>>> Am 07.07.22 um 14:57 schrieb Arno Welzel:
>>>
>>>>
>>>> rsync macht das schon mal nicht - wenn das abbricht, bleiben die Reste
>>>> halt ewig stehen.
>>>>
>>>
>>> Wenn man --partial verwendet. Sonst wird unvollständiger Müll entsorgt.
>>> Zumindst bei mir.
>>
>> Kann ich nicht bestätigen. Wenn der rsync-Prozess abgebrochen wird, wird
>> da nichts augeräumt - wie auch?

[...]

> Kommt wahrscheinlich auf die Art des 'Abbruchs' an, ob irgendein
> atexit() noch aufräumen kann.

Ja. Wenn der Prozess normal beendet wird (und Ctrl+C ist ja ein normales
Beenden und kein harter Abbruch des Prozesses), kann er natürlich
aufräumen. Ich dachte eher an Fälle, wo der Prozess nicht mehr sauber
beendet wird und deshalb Dateien übrig bleiben.

Worauf ich hinaus will: solange es keinen Dienst gibt, der im
Hintergrund die von rsync angefangenen Übertragungen irgendwo
protokolliert und bei Bedarf Dateifragmente aufräumt, können immer Reste
übrigbleiben, wenn ein Prozess unerwartet abgebrochen wird.

[Markus Franzke]

Am 14.07.22 um 09:45 schrieb Arno Welzel:
> Markus Franzke:
>

>> Kommt wahrscheinlich auf die Art des 'Abbruchs' an, ob irgendein
>> atexit() noch aufräumen kann.
>
> Ja. Wenn der Prozess normal beendet wird (und Ctrl+C ist ja ein normales
> Beenden und kein harter Abbruch des Prozesses), kann er natürlich
> aufräumen. Ich dachte eher an Fälle, wo der Prozess nicht mehr sauber
> beendet wird und deshalb Dateien übrig bleiben.
>
> Worauf ich hinaus will: solange es keinen Dienst gibt, der im
> Hintergrund die von rsync angefangenen Übertragungen irgendwo
> protokolliert und bei Bedarf Dateifragmente aufräumt, können immer Reste
> übrigbleiben, wenn ein Prozess unerwartet abgebrochen wird.
>
>

Um schwerere Fehler zu simulieren, hätte ich stärker ins System
eingreifen müssen. Das war mir die Sache dann nicht wert.

Fest steht:

1. Rsync liefert beim Absterben der Gegenseite einen Resultcode <> 0.

2. Auf der Gegenseite bleiben Artefakte mit jedesmal anderem Namen
übrig, wenn während der Übertragung hart abgebrochen wird.

Beides zusammen ermöglicht durchaus eine überwachte Übertragung. Auf der
Gegenseite löscht man alle Dateien, die diesem tempnam() ähnlichen
Schema entsprechen, sofern vorhanden. Auf der lokalen Seite wertet man
den Resultcode aus.

Ich mache seit Jahren meine Backups mit einem verteilten rsync-Konzept
inklusive Protokollierung und bin hochzufrieden, weil alle Aspekte, die
mir wichtig sind, beachtet wurden. Das beginnt mit dem Erhalt der Rechte
und Eigentümer, der Links ... und endet bei --modify-window, wo die FAT
FS nur gerade Sekunden können, sowie --bwlimit für USB-Sticks, die ich
'gebremst' betreiben muß, damit sie nicht thermisch verenden.

M