little_pixel schrieb:
Das Ergebnis ist erschreckend. Für die eine 20GB-Datei benötigt er dann ~2 Minuten.
cp und "gleichzeitig" md5
Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen
-
-
Kann ich leider nicht bestätigen…
Ich habe den Rechner neugestartet und nur cp und danach rsync gestartet.
Ich habe dabei auch auf die Uhr geschaut.
cp benötigt für die 20GB gerade mal um die 20 Sekunden.
rsync über zwei Minuten. Und da ist nichts mit Prüfsumme dabei.
In dem Order 1 liegt nur ein Test.sparseimage…
Viele Grüße
Quellcode
- Mein-MacBook-Pro:~ ichbins$ time cp -R /Users/ichbins/Downloads/1 /Users/ichbins/Downloads/2
- real 0m17.916s
- user 0m0.024s
- sys 0m12.872s
- Mein-MacBook-Pro:~ ichbins$ time rsync -a /Users/ichbins/Downloads/1 /Users/ichbins/Downloads/2
- real 1m55.855s
- user 1m40.373s
- sys 1m14.723s
- Mein-MacBook-Pro:~ ichbins$
-
Doch, rsync erstellt eine Checksum wenn du es nicht deaktivierst.
Schau dir einfach die CPU-Auslastung an: die sollte bei rsync hoch sein weil eben der MD5 berechnet wird.
Bei cp sollte die CPU-Auslastung hingegen so gut wie auf 0 sein weil die CPU beim Kopieren ja nichts zu tun hat. -
Warum erstellt es eine Prüfsumme?
Laut Beschreibung würde das nur stattfinden, wenn schon eine entsprechende Datei mir gleicher Größe etc. existiert.
Mein Zielordner ist aber leer…
manoh meint ja, dass es gleich lahm bei ihm funktioniert.
Das kann so auch nicht stimmen. Bei mir ist reproduzierbar, dass cp deutlichst schneller ist.
cp und nachträglich md5 ist sogar schneller, als mit rsync zu arbeiten.
Viele Grüße -
Weil rsync wohl nach der Übertragung der Daten nochmal die Prüfsumme generiert um sicher zu stellen dass die Daten auch korrekt angekommen sind.
-
Wieso geht eigentlich cp bei mir so langsam.??? - Ach, macht da die zsh etwas bzw. oh-my-zsh? Muss ich mir mal angucken...
-
Bei mir ist
rsync -a
reproduzierbar "schneller", als wenn ich manuell die Quelldatei hashe, mitcp
kopiere und danach wieder die Zieldatei hashe. Aber der Unterschied liegt effektiv bei nur 10%.*
Update: Ca. doppelt so großes Image. Ergebnis: Bei gleichem Test beträgt der Vorsprung von rsync ca. 15%.
*Testumgebung: rsync 2.6.9; 8,3 GiB ISO Image; 2x Kingston HyperX SSD (ext. USB3 Gehäuse mit Norelsys NS1066 Bridge)
* Kann Spuren von Erdnüssen enthalten.Dieser Beitrag wurde bereits 7 mal editiert, zuletzt von NSObject () aus folgendem Grund: Details ergänzt, Tippfehler, Update
-
Huhu,
ich habe Gestern die Innov8 für mein privates Archiv erhalten.
Damit habe ich einige Tests gemacht. Kopiert habe ich wieder eine Datei mit 20GB.
Mein-MacBook-Pro:~ ichbins$ time cp -R /Users/ichbins/Downloads/1/ /Volumes/Innov8/
real 1m50.528s
user 0m0.086s
sys 0m20.715s
Mein-MacBook-Pro:~ ichbins $ time rsync -a /Users/ichbins/Downloads/1/ /Volumes/Innov8/
real 2m29.465s
user 1m44.259s
sys 1m20.627s
Das Ziel ist aber "nur" eine HD und keine SSD. Da ist der Unterschied nicht mehr so extrem.
Aber auf der internen SSD ist rsync gegenüber cp immer mega langsam.
Ich teste es nachher mal noch mit einer USB-C SSD…
Viele GrüßeDieser Beitrag wurde bereits 1 mal editiert, zuletzt von little_pixel ()
-
das ist weil cp eben keinen hash zum überprüfen erstellt.
rsync hingegen erstellt einen hash beim einlesen der datei, dann wird die datei übertragen und dann nochmal ein hash erstellt um zu überprüfen dass die übertragung fehlerfrei ablief. Das ist natürlich langsamer als einfaches kopieren.
Aber du möchtest ja einen hash haben.
Wenns dir aber um das letzte quentchen speed geht, dann programmier das doch selbst. lies jeweils 10 MB (oder eben einen passenden brocken) ein, aktualisiere die prüfsumme damit und schreibe den brocken dann an seine destination. Das ganze kannst du dann mit so vielen threads laufen lassen wie du CPU-kerne hast. Das lesen/schreiben wird dadurch zwar nicht schneller aber du eliminierst im besten fall die zeit fürs erstellen der prüfsumme. -
Yep, das hatte wir ja alles schon…
Nur schreibt ja auch NSObject neben manoh auch, dass es bei ihm gleich schnell bzw. schneller sei.
Ich kann das leider nicht bestätigen. Da liegen bei mir Welten dazwischen. Was ich auch mit Deiner Begründung deckt.
Deshalb nochmals meine Antwort…
Viele Grüße -
little_pixel schrieb:
Yep, das hatte wir ja alles schon…
Nur schreibt ja auch NSObject neben manoh auch, dass es bei ihm gleich schnell bzw. schneller sei.
Ich kann das leider nicht bestätigen. Da liegen bei mir Welten dazwischen. Was ich auch mit Deiner Begründung deckt.
Deshalb nochmals meine Antwort…
Viele Grüße
-
Also bei mir sind die Teilschritte deutlich schneller, als mit rsync.
Unklar ist ja auch, ob sie sich %C ausgeben lassen haben.
Zumal, insofern ich das richtig gelesen habe, rsync bei der Zieldatei eben keine Prüfsumme mehr bildet.
D.h. dass eben beim Lesen und Übertragen die Prüfsumme verwendet wird.
Ob aber die Datei richtig auf dem Zielmedium liegt ist unklar.
Nur ob sie korrekt übertragen wurde. D.h. dass man schon noch ein md5 nach dem Kopiervorgang ausführen müßte.
Ist jetzt aber auch alles theoretisch…
In der Praxis habe ich Vorgestern einfach mal md5 über den Datenbestand angestoßen und laufen lassen.
Da ich den neuen Verbund noch nicht habe ist es auch nicht eilig. Aber so habe schon mal die Prüfsummen.
Mache ich dann einfach nochmals am Ende vom eigentlichen Kopiervorgang auf dem Zielmedium.
Viele Grüße -
korrekt, rsync liest die datei nach dem restellen auf dem zeillaufwerk nicht nochmal ein um die prüfsumme zu erstellen sondern verwendet die prüfsumme nur um den korrekten transfer zu verifizieren.
-
Fummelt Apple eigentlich beim nächsten Update an meinem neuen rsync rum?
Die Version, die Apple ausliefert, ist ja schon alt.
Viele Grüße -
little_pixel schrieb:
Fummelt Apple eigentlich beim nächsten Update an meinem neuen rsync rum?
Die Version, die Apple ausliefert, ist ja schon alt.
Viele Grüße
-
Danke.
In habe das Original überschrieben…
Viele Grüße -
Huhu,
ich habe zu dem Thema eine ergänzende Frage:
Ich habe einen ganzen Karton voll alter HDs, die ich jetzt kopieren möchte…
Via Finder ist das nicht möglich, da der bei jedem Fehler abbricht.
Deshalb nehme ich cp und rsync. Da funktioniert weitgehend gut und ich bekomme die kaputten Dateien gelistet.
Mein Problem ist aber, dass ich einige Platten habe, bei denen beim Kopieren ein Kernel Panic auftritt.
Wenn ich jede Datei einzeln Kopiere, dann kann ich den Übeltäter finden und nicht mehr anrühren.
Meine Frage ist nun aber, ob ich die Dateien ausfindig machen kann.
Mit cp werden die kaputten Dateien zwar gelistet, aber die die ein Kernel Panic verursachen bringt mir das so wenig.
Viele Grüße -
hab da ein paar anregungen:
- brauchst du keine resource forks (fonts, alte bookmarks, alte text clippings etc)?
- wenn du protokollierst welche datei du jetzt bewegen willst (vorher ins file flushen) siehst du auch bei welcher es eine KP gibt (wenns viele dateien sind führt das natürlich nirgends hin).
- eventuell kannst dus auch mal mit einem live-linux versuchen (einfach auf einen USB-Stick laden, von dem booten HFS-treiber installieren und loslegen). -
Hallo Gabriel,
vielen Dank für die Hinweise.
Ich habe es noch mit dd probiert und damit kommt kein Kernel Panic.
Mit einem kleinen Skript lasse ich jede Datei einzeln kopieren.
Wenn dd "unendlich" Zeit benötigt und einen Haufen an Fehler spuckt, dann schieße ich den Vorgang ab und sehe die Datei einfach als verloren an.
Viele Grüße
-
Ähnliche Themen