[Erledigt] Rechenleistung beim Kopieren von Bedeutung?

[wanne]

Üblicher Schreib/Lesespeed von ner SSD sind 3GBit/s.

Nicht ganz, SATA macht nur 2.4GBit/s.

[/quote]Nein SATA kann bis zu 1.97 GB. Siehe auch: https://en.wikipedia.org/wiki/Serial_AT ... ther_buses
zugegebener weise machen die meisten SSDs entweder SATA mit 600MByte/s oder M.2 oder NVMe mit U.2.

[MSfree]

Nur dd ist so dämlich nacheinander zu lesen und zu schreiben.

cp aus coreutils/src/copy.c macht es auch so, also schön nacheinander read/write, da ist nichts parallelisiert und gepipelined.

Bei cat hast du zumindest die Parallelisierung durch die zwei Prozesse "cat" und die laufende Shell, so daß das Lesen vom cat-Prozeß kommt und die Ausgabeumleitung mit ">" die Shell übernimmt.

Alle anderen tools machen das parallel.

Bestimt nicht "alle". Ich gehe sogar so weit, zu sagen, daß praktisch gar kein Tool intern irgendetwas parallelisiert hat.

Wenn duin deinem 100 Mal schnelleren RAM kopierst ist dd schneller wie cp auf der Platte welch wunder.

Nunja, ganz dumm bin ich nun auch wieder nicht. Ich habe dd und cp zweimal ausgeführt, so daß die Ausgangsdatei auf jeden Fall spätestens beim zweiten Lauf im Cache war. Die jeweils schnelleren Zeiten hatte ich aufgeführt: Vorteil dd.

Und zumidest in dem Scenario, das ottonormal durchgeführt hat, also Nutzung von USB3-SATA-Wandlern bist du auf 2.4GBit/s auf der SATA-Seite beschränkt.

[atarixle]

dd ist nur für eines gut: man bestimmt hier die Größe des auf einmal zu lesenden Blocks. Dies kann die Lese-/Schreibgeschwindigkeit beeinflussen. Ansonsten halte ich es auch für extrem lahm, wenn ich das mit drag'n'drop unter irgend einer Oberfläche vergleiche.

Wenn du die Platte spiegeln willst, kannst du auch cat oder cp nutzen, ich selber nehme auch nur aus Gewohnheit dd.

Wann immer es mir möglich ist, lass ich aber den Verzeichnisbaum auf Datei-Ebene duplizieren.

[TomL]

TomL hats ja schon erwähnt.

Ja, ich habe allerdings vorher (!) für gleiche Bedingungen gesorgt, in dem ich vorher das grml.iso einmal nach x.iso kopiert habe. Mit der Vermutung, dass -wenn Cache- der für die beiden dann folgenden Vergleiche gleichermaßen greift. Und vor dem Hintergrund ist cp deutlich schneller.

[wanne]

cp aus coreutils/src/copy.c macht es auch so, also schön nacheinander read/write, da ist nichts parallelisiert und gepipelined.

Nein. Guck dir das Verhalten an. Die Magic steckt im read() der glibc. Das lässt den Kernel schonmal die nachfolgende Bytes vorsorglich lesen, wenn man ro geöffnet hat. – Solange man das nicht per fcntl kaputt macht. – Das lesen passiert dann parallel zum write() im cp. Wenn cp dann das nächste mal read() macht ist das weitestgehend instand fertig, weil die glibc das schonmal in vorauseilendem gehorsam gemacht hat.

Bestimt nicht "alle". Ich gehe sogar so weit, zu sagen, daß praktisch gar kein Tool intern irgendetwas parallelisiert hat.

Mann muss sich schon sehr anstrengen das oben genannte verhalten kaputt zu bekommen. Deswegen habe ich gemeint, dass das defakto jedes Programm nutzt. Die haben das nicht alle selbst implementiert. Es ist einfach da.

Bei cat hast du zumindest die Parallelisierung durch die zwei Prozesse "cat" und die laufende Shell, so daß das Lesen vom cat-Prozeß kommt und die Ausgabeumleitung mit ">" die Shell übernimmt.

Nein.> Übernimmt nicht die schell sondern übergibt nur den fd an cat. Du kannst dasda machen: cat a > b & exit dann hast du keine schell mehr aber das cat läuft weiter durch.

Nunja, ganz dumm bin ich nun auch wieder nicht. Ich habe dd und cp zweimal ausgeführt, so daß die Ausgangsdatei auf jeden Fall spätestens beim zweiten Lauf im Cache war. Die jeweils schnelleren Zeiten hatte ich aufgeführt: Vorteil dd.

Die aussage ist schlicht gelogen.
400MiB im RAM kopiere mit cp selbst auf meinem T420 nie mehr als 0.3s. Mit dd bin ich imme bei ~2s. Wie gesagt: Kann jeder mal selber nachbauen. Wenn man das oft genug macht läuft man etwa auf den Faktor 10 raus. – Außer natürlich der User heißt MSfree.

Und zumidest in dem Scenario, das ottonormal durchgeführt hat, also Nutzung von USB3-SATA-Wandlern bist du auf 2.4GBit/s auf der SATA-Seite beschränkt.

Ja eher deutlich stärker. Die 2.4GBit/s bekommst du eher nicht durch USB3. Deswegen ja meine empfehlung richtung nativen SATA. Und dafür war meine Überschlagsrechnung schon nicht schlecht. – Auch wenn sie mit 1Byte==10Bit gerechnet hat.
Edit: Die 2.4GBit/s sind natürlich totaler Unfug. 4,80GBit/s sind die Nettodatenrate von allen gebräuchlichen SATA-Anschlüssen. SATA II hat seit Jahren keiner mehr verbaut. Ich bin ohne weiter nachzudenken davon ausgegangen, dass du meine Umrechnung von 600MByte/s auf 6GBit/s kritisiert hast.