Fragen? Antworten! Siehe auch: Alternativlos
Normalerweise nimmt man für sowas ja cp. Nur ist das bei cp so, dass man eben nicht direkt auf die Platte schreibt, sondern in den Buffer Cache. Sowas kann man unter Unix prächtig mit vmstat 1 beobachten. Da gibt es eine Spalte "bi" für "block in" und eine "bo" für "block out". Bei cp sieht man dann erst fünfstellige Werte bei bi Spalte, und Null bei bo. Dann läuft der Plattencache voll und bo geht hoch. Dafür geht dann bi runter. Denn das write() in den Buffer cache bleibt stehen, wenn da kein Platz ist, bis wieder Platz ist, was eben heißt, dass der Kernel was rausgeschrieben hat. In der Praxis ergibt sich ein "pumpendes" Verhalten, wo sich in- und output immer abwechseln. Keinesfalls eine optimale Ausnutzung der Bandbreite zu den Platten.
Also habe ich in mein cp aus den embutils mal einen Switch -s eingebaut. Der öffnet die Zieldateien dann mit O_DIRECT. Das weist den Kernel an, die Daten direkt auf die Platte zu hauen, und nicht erst durch den Buffer Cache zu puffern. Das hat immer deutlich geholfen beim Durchsatz.
Nun hat sich in letzter Zeit einiges geändert. Wir haben ext4 als Filesystem, ich habe genau das Problem mal mit Ted T'so angesprochen, und er hat da was getuned, und meine Platten machen jetzt jeweils so 100 MB/sec.
Und jetzt habe ich den Effekt, dass cp -s plötzlich nur noch 25 MB/sec Durchsatz schafft. Wenn ich aber auf dem Quellplatte einen gatling starte und dann über localhost per wget oder so die Daten ziehe, habe ich 94 MB/sec. Nun kann man das argumentieren, dass cp -s langsamer sein kann. So liest der ja nicht weiter, während er auf das Schreiben wartet. Aber dass er auf ein Viertel der Nennbandbreite einbricht, das ist krass.
Anyway, wird noch lustiger. Wenn ich cp ohne -s benutze, also reguläres cp, dann kriege ich 75-80 MB/sec. Also immer noch weniger als wenn ich die Daten über gatling und das loopback-Interface transferiere!
Da sieht man mal, worauf heutige Betriebssysteme so optimiert sind! :-)
Update: Noch eine spannende Beobachtung: mmap+write mit 128k-Blöcken bringt deutlich weniger Durchsatz als read+write mit 16k-Blöcken.