rsync

[Thorsten2000]

Hallo,

mittlerweile habe ich es hinbekommen, mit rsync meinen aktuellen Arbeitsordner regelmäßig auf meine iDisk sichern zu lassen. Mit der -v Option eingeschaltet ist mir aufgefallen, dass er dafür doch mehr Zeit benötigt, als ich dachte. Ist es nicht so, dass rsync nur die Checksummen prüft und dann nur die Veränderungen überträgt? Also quasi nur die fünf Sätze, die ich gerade in mein rtf-Dokument geschrieben habe?

Er braucht aber, immer wenn er über cron startet (alle halbe Stunde) immer so knapp 10 Minuten, bis er fertig ist - obwohl der zu synchronisierende Ordner nur aus fünf Dateien mit insgesamt 1,1 MB besteht. Und am Ende der Ausgabe sagt er ja auch, wie viel übertragen wurde, und das sind immer diverse 100000 bytes.

Ist es wirklich so, dass er nur das neue überträgt oder habe ich da in der man-page eine option übersehen, die ich dafür setzen muss?

Viele Grüße,
th.

 

[maceis]

Um zu prüfen, wie lange ein Kommando benötigt, würde ich eher das 'time' Kommando empfehlen. -v beansprucht zusätzliche Zeit.

Im Übrigen kommt es bei rsync nicht nur darauf an, wieviele Dateien/Bytes tatsächlich übertragen werden müssen, sondern auch, wieviele Dateien (evtl. über eine langsame remote Verbindung) abgeglichen werden müssen.

 

[Thorsten2000]

Danke. Dann liegt es wahrscheinlich daran, dass einige Ulysses-Dateien dabei sind, und das sind ja bekanntlich packages mit wiederum recht vielen Einzeldateien. Dann dauert also das Abgleichen seine Zeit, aber er lädt deswegen noch lange nicht hoch.

 

[?=?]

afaik wird eine iDisk unter "/Volumes" eingebunden.
Demnach sieht es für rsync so aus, als ob nur lokale Dateien miteinander synchronisiert werden sollen.
Vermutung: Das rsync-Verfahren zur Bestimmung der geänderten Teile funktioniert in solch einer Konstalletion nicht bzw. ist nicht nutzbar.
Wie soll rsync feststellen welche Teile geändert wurden, ohne "beide Seiten" zu lesen?
Wenn rsync von/auf eine remote-Maschine geht wird afaik dafür entweder eine shell oder ein rsync-Server genutzt. Beides versetzt rsync in die Lage, die Dateien auf der remote-Maschine dort lokal (d.h. ohne Netzwerk-Traffic) zu lesen und zu analysieren. Vermutlich werden für einzelne Teile Checksummen gebildet, die dann übers Netzwerk übertragen werden, um die Differenzen festzustellen.
Bei einem rsync auf deine iDisk hast du auf der "remote"-Seite aber weder eine Shell, noch einen rsync-Server. Stattdessen werden höchstwahrscheinlich beide Seiten direkt ("lokal") gelesen, was im Normalfall ja auch kein Problem ist, da lokale Dateizugriffe nicht unter Netzwerklaufzeiten leiden.

Ich hoffe, ich habe mich verständlich ausgedrückt.

Wenn die Theorie stimmt geht's vielleicht mit "--whole-file" (sollte allerdings default sein, s.u.) und ohne "--checksum" (falls du das angegeben hast) schneller. Das würde zumindest das zusätzliche "lokale" Lesen der Files für die Bestimmung der Differenzen ersparen.

-W, --whole-file
With this option the incremental rsync algorithm is not used and
the whole file is sent as-is instead. The transfer may be
faster if this option is used when the bandwidth between the
source and destination machines is higher than the bandwidth to
disk (especially when the "disk" is actually a networked
filesystem). This is the default when both the source and des-
tination are specified as local paths.

?=?

 

[Thorsten2000]

Ich habe jetzt erstmal mit der option -t getestet, mein Befehl sieht nun so aus:

rsync -atE --delete ~/Texte /Volumes/meine-iDisk/Documents

-t sollte bewirken, dass nur die geänderten Teile übertragen werden. Mir scheint die ganze Sache jetzt auch schneller zu gehen, aber nach wie vor steht, auch wenn nix geändert wurde, bei jedem Durchlauf die aktuelle Uhrzeit hinter den Dateien auf der iDisk. Es ist nicht wirklich wirklich super langsam, aber doch langsamer als ich erwarten würde für gerade mal 1 MB, wenn sich nix geändert hat.

Ein weiterer Test mit der Option -c (always checksum) ergab dann aber einen deutlichen Geschwindigkeitsgewinn, und auf der iDisk bleibt bei den Dateien das alte Änderungsdatum bestehen, wenn sich nix geändert hat.

Die Lösung lautet also -c

Vielen Dank an alle!

 

[cwasmer]

Das muss ein Problem mit iDisk sein. Ich syncronisiere regelmässig meinen gesamden "Documents"-Ordner mit 8500 Dateien, 4.5 GB zwischen Server und Laptop. Das dauert 2 Sekunden (keine Änderungen, rsync in beide Richtungen) und ist ansonsten nur durch die Übertragungsrate begrenzt.
Ich benutze -abvuz

 

[Thorsten2000]

habs jetzt auch mit -abvuz probiert, geht recht schnell, allerdings deutlich langsamer als 2 sek für 4,5 Giga. Eher so 10-15 sek für 1,5 MB. Dann ist es wohl wirklich die idisk. Und die Option -E scheint auch etwas Zeit zu kosten.

Dass die iDisk langsam ist, war ja bekannt, aber ich dachte immer, das liegt am Finder.

***
edit: ich machs jetzt auch mit -abuz, ist doch noch mal deutlich schneller als meine vorherige Lösung. Ich frage mich nur, ob -E nicht wichtig wäre (obwohl es deutlich slower wird damit), mit dieser Option werden doch die ganzen OS X Forks erhalten, ich dachte, das wäre wichtig?

 

[?=?]

@ Thorsten2000
Soweit ich das verstehe ist "-E" unbedingt erforderlich, um erweiterte Attribute (=> Spotlight Tags), Resource Forks und ACLs zu übertragen.

Kannst du einfach ausprobieren, indem du einer Datei im Finder über "Information" zusätzliche "Spotlight Kommentare" zuweist.

Noch eine Warnung am Rande: Ich habe letztens wie blöd gesucht, um herauszufinden, warum eine laut rsync problemlos zwischen zwei Linux-Systemen übertragene Datei auf dem Remote-Rechner nicht aktualisiert wurde: Das Ziel-Filesystem war voll. Soweit - so schlecht. Ich hätte dabei allerdings eine Fehlermeldung von rsync erwartet! Aber trotz "-vv" meinte rsync, alles ist O.K. gelaufen .


?=?

 

[Thorsten2000]

Hallo!

@ Thorsten2000
Soweit ich das verstehe ist "-E" unbedingt erforderlich, um erweiterte Attribute (=> Spotlight Tags), Resource Forks und ACLs zu übertragen.
Kannst du einfach ausprobieren, indem du einer Datei im Finder über "Information" zusätzliche "Spotlight Kommentare" zuweist.

Wenns nur darum geht - darauf kann ich verzichten. Umso besser, da es ja ohne -E schneller geht.

... nicht aktualisiert wurde: Das Ziel-Filesystem war voll. Soweit - so schlecht. Ich hätte dabei allerdings eine Fehlermeldung von rsync erwartet! Aber trotz "-vv" meinte rsync, alles ist O.K. gelaufen

hm, hoffe trotzdem dass das verlässlich ist. Zielvolume wird bei mir aber wohl nie voll werden, weil ich mit rsync wirklich nur die Sachen - in der Regel Texte - synchonisiere, an denen ich wirklich gerade arbeiten. Mehr als ein paar MB dürften das nie werden.