Alexander Holler <holler_at_ahsoftware.de> wrote: > >> Wobei ich von rsync für solche Sachen nicht viel halte. Das ist eine > >> echte Qual für die Server und per FTP bzw. HTTP lässt sich viel > >> resourcenschonender spiegeln. > > > > Das glaube ich nicht. > > Ist aber so, zumindest im Normallfall. Denn dabei überprüft rsync immer > per Prüfsumme das was übertragen wurde. Und die muss auf Senderseite ja > auch erst berechnet werden. Nein, der Normalfall beim Spiegeln ist, die Zeitstempel zielseitig zu setzen (-t), und dann überspringt rsync den Prüfsummenvergleich, wenn sich an den Zeitstempeln nichts geändert hat. Das erfordert immer noch ein stat() auf jede Datei, aber das machen FTP/HTTP-Server auch. > Und davon abgesehen, glaub ich nicht, daß rsync so auf den > Massenbetrieb optimiert wurde, wie z.B. ein Apache o.ä. In der Praxis sind rsync-Server typischerweise durch Disk-I/O begrenzt. Wenn man effizienter als rsync arbeiten will, dann muss man (1) sicherstellen, dass die Daten sich nur kontrolliert ändern, was erlaubt, (2) die Metadaten (Dateinamen, Zeitstempel, Länge) in einem Cache zwischenzuspeichern. Dann müssen nur die Daten aus dem Cache verglichen werden, statt den Dateibaum rekursiv zu durchqueren und auf alle Einträge ein stat() zu machen. CVSup und CVSync können das so handhaben; der Zugewinn bei Daten, die aus vielen kleinen Dateien bestehen, ist drastisch. > ich würde rsync aber nicht benutzen um damit "der Masse" Dateien > anzubieten. "Die Masse", im Sinn von Webbrowser-Klickern, weiß ja auch gar nicht, dass rsync existiert. Die Zielgruppe, die tatsächlich Daten spiegeln will, dagegen schon und dort ist rsync das Protokoll der Wahl. -- Christian "naddy" Weisgerber naddy_at_mips.inka.de -- http://mailman.uugrn.org/mailman/listinfo/uugrnEmpfangen am 30.06.2007
Dieses Archiv wurde generiert von hypermail 2.2.0 : 30.06.2007 CEST