[Erledigt] Rechenleistung beim Kopieren von Bedeutung?

[ottonormal]

Hallo,

ich plane eine SSD mit 500GB per dd auf eine andere, gleichgroße SSD zu kopieren. Beide SSDs stecke ich dazu in ein ext. USB-Gehäuse. Da das ja wohl einige/viele Stunden in Anspruch nehmen wird, würde ich gerne wissen, ob der Vorgang auf einem etwas leistungsschwächeren Rechner (Intel NUC Barebone BOXNUC7I3BNH) wesentlich länger dauert als auf meinem stärkeren Arbeitsrechner. Der würde dann ja so lange blockiert.
Oder einfacher gefragt, spielt die Rechnerleistung bei einem einfachen Kopiervorgang eine wesentliche Rolle?

Ist vielleicht eine etwas blöde Frage, ich kann mir das aber irgendwie nicht vorstellen.

[DeletedUserReAsG]

spielt die Rechnerleistung bei einem einfachen Kopiervorgang eine wesentliche Rolle?

Nicht nennenswert. Es sei denn, es ist irgendwo Verschlüsselung im Spiel, und die Hardware kann’s nicht, so dass es in Software gemacht werden muss. Ansonsten sind eher die Bandbreiten der Datenträgeranschlüsse, oder die der Datenträger selbst die limitierenden Faktoren. Etwa die 20-30MB/s bei USB2.

[ottonormal]

Danke!
So ähnlich hatte ich es mir erhofft. Dann werd' ich das auf dem Kleinrechner mal in Angriff nehmen. Mal schauen wie lange der braucht

[debianoli]

Wie sieht es eigentlich mit dem RAM aus? Gibt es da eine Faustregel, wieviel RAM beim Kopieren benötigt wird, um eine bestimmte Geschwindigkeit zu erreichen? Oder ist das relativ egal?

[ottonormal]

Wie sieht es eigentlich mit dem RAM aus?

Ja, das würde mich auch noch interessieren. In meinem Arbeitsrechner habe ich 16 GB und in dem Kleinrechner sind 8 GB. Macht das einen (wenn überhaupt) großen Unterschied?

[wanne]

Oder einfacher gefragt, spielt die Rechnerleistung bei einem einfachen Kopiervorgang eine wesentliche Rolle?

Nein. Kopieren braucht erst mal gar keine Rechenleistung.
Lediglich die Anweisung zum kopieren und eventuell das auffinden im Dateisystem.
Problem ist, dass alle Linux-Programme die Daten Zuerst in den RAM kopieren müssen und dann vom RAM auf die Platte. (Es geht das ohne den Umweg RAM zu machen. Aber nicht unter Linux oder einem anderen "echten" Betriebssystem.) Das passiert in kleinen Stücken. => Du kopierst mehrfach Einzelteile. => Die Arbeit fällt mehrfach an. Du willst also so große Teile kopieren, dass das kopieren Länger dauert als das erteilen der Instruktion. Das ist üblicher weise bei ~4kiB der Fall.
Womit geklärt ist wie viel RAM du brauchst, um Optimal schnell zu kopieren: Deutlich mehr als 4kiB. (Ich nehme an das hast du.)
Fette Ausnahme ist dd: Der kopiert zuerst in den RAM; rechnet; kopiert auf die Festplatte; rechnet; ... Alles nacheinander. Damit brauchst du deutlich länger und schnellere CPUs bringen tatsächlich einen minimalen Speedup Wenn du bs= um ein vielfaches größer als 4kiB setzt, merkt man den Unterschied aber irgend wann nicht mehr, weil das rechnen zwischen den Kopiervorgängen zwischen der Zeit der Kopiervorgänge vernachlässigbar ist.
Kurz: Nimm kein dd sondern cp oder cat.
Was die Geschwindigkeit wirklich Limitiert ist a) die Geschwindigkeit deiner SSD (~4-16GBit/s). b) die Geschwindigkeit der Anbindung (SATA (~6GBit/s), PCIe/M.2 (~8GBit/s)/NVME (~24GBit/s)) und c) die Geschwindigkeit deines RAMs (DDR4 2*~150GBit/s). Da letzeteres defakto deutlich schneller ist, ist das Wurst.

Beide SSDs stecke ich dazu in ein ext. USB-Gehäuse.

USB braucht aber erhebliche Rechenleistung. Das ist dann nicht mehr so einfach vernachlässigbar.
Für USB 2 brauchst du etwa einen Core Duo. Oder etwa ein fünftel Core auf ein Intel Core iX.... (So viel tut sich da gerade nicht, was die Rechenleistung beim Kopieren angeht. Da ist halt vor allem Takt entscheidend. Und der hat sich nicht so viel verändert.) Das sind dann die ~250MBit/s. Für schnelles Übertragen bei USB 3.1 ist die Geschwindigkeit deiner CPU dann wieder relevant. Allerdings habe ich eh praktisch noch nirgends irgend welche USB-Hardware gesehen, die wirklich an die Limits dran kommt. Am Ende bestimmt dein externes USB-Dinges, das bestimmt wie schnell du bist. => Wenn du speedup willst nimm kein USB. Ist auch gut für die Umwelt.

[reox]

solange irgendwo DMA im Spiel ist, sollte es ohne viel RAM und ohne viel CPU gehen.
Du könntest zB Firewire verwenden, das kann DMA - damit könnte es sogar mit weniger Leistungsanforderung als USB gehen. Aber wer will Firewire

[wanne]

solange irgendwo DMA im Spiel ist, sollte es ohne viel RAM und ohne viel CPU gehen.
Du könntest zB Firewire verwenden, das kann DMA - damit könnte es sogar mit weniger Leistungsanforderung als USB gehen. Aber wer will Firewire

Meine ausführungen haben sich ja schon auf DMA. Also SATA, PCIe, NVME bezogen. ist ja defakto nur USB dass das nicht kann.

[ottonormal]

Das war ja jetzt sehr ausführlich . Vielen Dank dafür.
An dd werde ich aber wohl nicht vorbeikommen, die Partitionen auf der zu kopierenden Platte sind verschlüsselt. Noch bin ich auch gar nicht so weit weil die neue Platte noch gar nicht da ist. Die kommt erst im Laufe der nächsten Tage. Letztendlich kommt es mir auch nicht drauf an ob der Kopiervorgang nun 10 oder 11 Std. dauert. Nur wenn es auf dem kleinen Rechner dann vielleicht 20 statt 10 Std. sind, dann würde ich es wohl anders machen.

Firewire habe ich nicht. Obwohl ich noch ein recht gutes Firewire-Audiointerface habe .

[wanne]

An dd werde ich aber wohl nicht vorbeikommen, die Partitionen auf der zu kopierenden Platte sind verschlüsselt.

Ja und?! Gerade bei verschlüsselten Devices kannst du ja gar keinen Gebrauch von den Konvertierungsfunktionalitäteten von dd machen.

Code: Alles auswählen

cat /dev/sda > /dev/sdb

ist deutlich mehr als doppelt so schnell wie

Code: Alles auswählen

dd if=/dev/sda of=/dev/sdb

Das Ergebnis ist das selbe. Ähnlich schnell ist:

Code: Alles auswählen

cp /dev/sda /dev/sdb

Verstehe nicht, warum da immer dieses komische 70er Jahre Tool genutzt wird, nur weil es "disk" im Namen hat. Das ist einfach seit 30 Jahren nicht mehr Zeitgemäß. Im Normalgebrauch für Dateien benutzt das doch auch keiner mehr. (Obwohl man es da genauso statt cp und cat nutzen könnte.)

Nur wenn es auf dem kleinen Rechner dann vielleicht 20 statt 10 Std. sind, dann würde ich es wohl anders machen.

cat statt dd bringt dir über den Faktor 2. (Voraussetzung ist, dass die beiden Platten auch wirklich an verschiedenen Anschlüssen hängen. Also wenn du bei USB bleibst empfiehlt es sich mindestens eine hinten einzustecken. Die Front-USBs sind meistens nur ein USB-HUB, der an einem einzelnen USB-Anschluss hängt.) (e)SATA bringt dir bei gerne den Faktor 10 zu USB 2.0 und den Faktor 4 zu USB 3.0.
Leider Musst du da meistens einbauen, weil externe SATA Anschlüsse seit USB 3.0 eher selten sind. Ich nutze aus dem Grund noch immer ein T420, dass noch einen externen eSATA hat. Stein alt aber das, dass am schnellsten Daten hin und her kopieren kann.

[ottonormal]

Um dieses Thema hier zu Ende zu bringen:

Ich habe doch alle Kopiervorgänge mit dd gemacht. Schon aus alter Gewohnheit, in die anderen Kopiermethoden müsste ich mich sonst auch erst einarbeiten (auch wenn's vielleicht nicht soo schlimm wäre).

Also, ingesamt habe ich 5 verschlüsselte Partitionen von 2 SSDs auf 2 neue, gleichgroße SSDs kopiert.

Die zu kopierenden SSDs habe ich dazu in ein ext. USB-3-Gehäuse gesteckt, die neuen SSDs waren im neuen Mini-Rechner (PC BB Intel NUC Kit NUC7I3BNH Core i3- 7100U) eingebaut. Den Kopiervorgang selbst habe ich mit einem USB-Debian-Stick auf dem Mini-Rechner gemacht.

Insgesamt habe ich 1.138 GB kopiert. Das hat 401 Min. gedauert, also 6 Stunden 41 Minuten.
Ich bin der Meinung, dass das nicht zu viel ist, hatte eigentlich mit mindestens dem Dreifachen gerechnet und war dann überrascht, dass es doch so relativ schnell ging.

[wanne]

Insgesamt habe ich 1.138 GB kopiert. Das hat 401 Min. gedauert, also 6 Stunden 41 Minuten.

Üblicher Schreib/Lesespeed von ner SSD sind 3GBit/s. Wenn man das vernünftig macht ist man bei ca. 45min.
Und ich kann absolut nicht verstehen was so schwierig daran ist, das dd duch ein cp zu ersteren und das if= und of= wegzulassen. Der Rest bleicht ja exakt genau gleich.

[MSfree]

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

Nicht ganz, SATA macht nur 2.4GBit/s. Wenn man also über USB3 wirklich diese Datenrate voll ausschöpfen könnte, kommt man auf 63min. Das Kopieren von einer USB3-SSD auf die zweite halbiert die Datenrate dann nochmal, so daß man bei 126min endet, im günstigsten Fall. Dann noch ein wenig USB-Ineffizienzen draufgeschlagen, und man ist bei 252min.

Und dann noch etwas zu dd vs. cp:

Code: Alles auswählen

time cp firmware-buster-DI-rc1-i386-netinst.iso x1; sync

real    0m2,702s
user    0m0,004s
sys     0m0,404s

vs.

Code: Alles auswählen

time dd if=firmware-buster-DI-rc1-i386-netinst.iso of=x2; sync
958464+0 Datensätze ein
958464+0 Datensätze aus
490733568 Bytes (491 MB, 468 MiB) kopiert, 1,23008 s, 399 MB/s

real    0m1,236s
user    0m0,168s
sys     0m1,060s

Schade, daß cp doppelt so lange braucht wie dd.

[TomL]

Schade, daß cp doppelt so lange braucht wie dd.

Code: Alles auswählen

$ ls x.iso
-rw-r--r-- 1 thomas thomas 673M 2018-12-31 15:05 x.iso

$ time dd if=x.iso of=x2; sync
1376768+0 Datensätze ein
1376768+0 Datensätze aus
704905216 bytes (705 MB, 672 MiB) copied, 2,38675 s, 295 MB/s

real	0m2,391s
user	0m0,667s
sys	0m1,722s


$ time cp x.iso x3; sync

real	0m0,341s
user	0m0,000s
sys	0m0,341s

Ich tippe mal auf Reihenfolge....

[wanne]

Das Kopieren von einer USB3-SSD auf die zweite halbiert die Datenrate dann nochmal,

Genau das passiert nicht, wenn du cat verwendest. Nur dd ist so dämlich nacheinander zu lesen und zu schreiben. Alle anderen tools machen das parallel. Genau das ist der fette Nachteil von dd. (Dazu kommen noch die hässlichen defautls, was IO-Modi und Blockgrößen angeht.)

Und dann noch etwas zu dd vs. cp:

TomL hats ja schon erwäht. Wenn duin deinem 100 Mal schnelleren RAM kopierst ist dd schneller wie cp auf der Platte welch wunder. Spiel das gleiche doch nochmal am Ende mit cp durch. und guck dir den Speedup an... Im RAM ist locker der Faktor 10 drin.

[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.