Datenplatte spiegeln - "dd" oder "cp" Kopie?

[theSplit]

Moin!

Folgendes:
Ich möchte eine Festplatte, 1 TB, auf eine andere spiegeln mit 1 TB, dafür würde ich "dd" verwenden - so jedenfalls die erste Idee.

Es handelt sich allerdings um eine reine Datenplatte die nur eine Partition mit FAT32 bzw. NTFS (kann ich gerade nicht schauen, kann ich aber bei Bedarf nachreichen), beinhaltet, keine Bootsektoren oder sonstiges.

Jetzt wäre meine Frage, sollte ich zu "dd" greifen um die Platte 1 zu 1 zu spiegeln, defekte Sektoren sind meines Wissens auf dem Quellmedium keine vorhanden, oder doch weil einfacher einfach ein "cp -R * target" einsetzen?
Das Quellmedium ist bis auf ein paar GB auch komplett ausgelastet.

Was kopiert aber in diesem Fall schneller, ein "dd" mit Bulksize von 8 oder 16 MB - oder lieber das rekursive CP?

Es handelt sich um Mischdaten, viel "kleine" (1-30 MB) Dateien, ein paar größere.

Was wäre der schlaueste Weg in diesem Fall?

 

[alter_Bekannter]

Hängt davon ab wie viele Dateien es sind. DD wird die Platte mit hoher Geschwindigkeit halt komplett kopieren. CP hört auf wenns alle Daten zusammen hat ist aber langsamer.

Da wir von 1 TB reden hast du mit der Frage allerdings vermutlich schon mehr Zeit verschwendet als DD gebraucht hätte. In einer Stunde dürfte das erledigt sein.

 

[theSplit]

Naja, ob ich das zwischenzeitlich schon kopiert hätte, nein, bei 32 GB auf microSDs mit Bulksize von 8 MB braucht "dd" trotzdem oft 25-50 Minuten, bei 32 GB bzw. 16 GB Images...

Aber ich wollte halt generell mal wissen, was schneller wäre. Rein von der Theorie und Praxis.

 

[alter_Bekannter]

Ausrechnen, in CP zählt alles, in DD nur die Plattengeschwidigkeit durch Größe. Nur nach Speichervolumen ist DD immer schneller. CP geht von da an nur abwärts wenn alles kopiert werden soll und die Platte voll wäre. In der Realität ist aber keine Platte "voll".

CP analysiert das Dateisystem, DD interessiert sich dafür nicht.

Brutto ist DD daher immer schneller. Netto wirds wie immer komplizierter.

 

[theSplit]

DIe Platte ist, wie ich schrieb, bis auf ein paar GB voll - die würde "dd" ja auch mitkopieren (also die leeren GB) - wobei CP die ignorieren würde, weil es ja nur Dateien kopiert.

Aber wenn man die Datenstruktur ignoriert, sollte "dd" eigentlich doch noch schneller sein oder? - Weil eben alles, ohne Gnade, übernommen wird und einfach am Stück kopiert wird, während "cp" sich ja an den Dateibaum orientiert?
Ob die Daten jetzt fragmentiert sind oder nicht, spielt hierbei keine Rolle - falls das irgendwie mit einspielen sollte.

 

[alter_Bekannter]

Siehe Update die haben sich überschnitten. Die letzte Zeile sollte es beantworten.

 

[theSplit]

Brutto ist DD daher immer schneller. Netto wirds wie immer komplizierter.

Okay, das wäre eine Antwort.

Werd mal schauen, sobald ich kann, weil eben gerade noch Daten auf die Platte wandern, was dabei rauskommt. Werde mal die Zeit festhalten die "dd" dann braucht.

 

[alter_Bekannter]

Du kannst dir den Fortschritt anzeigen lassen.
https://askubuntu.com/questions/215505/how-do-you-monitor-the-progress-of-dd

Zeigt auch die aktuelle Geschwindigkeit. Die komplette durchschnittsgeschwindigkeit wird aber glaub ich immer anschließend angezeigt. Beim Plattenbenchmarken immer dran denken das die Caches bis 256Mb groß sein können also mindestens ein paar GB testen.

 

[theSplit]

"--status=progress" - kenn ich zum Beispiel von "dd".

Naja, das sind tragbare externe Festplatten, ich weiß nicht wie groß der Cache am besten sein soll, 16 MB? Oder doch mehr?

Ich weiß nicht ganz was du meinst mit:
"....das die Caches bis 256Mb groß sein können also mindestens ein paar GB testen"

genau aussagen soll. Lesegeschwindigkeit/Schreibgeschwindigkeit, sollte um die 16 MB betragen.

Sind "Intenso 1 TB Memory Case".

 

[alter_Bekannter]

Du kannst dir den Fortschritt anzeigen lassen.
https://askubuntu.com/questions/215505/how-do-you-monitor-the-progress-of-dd

Zeigt auch die aktuelle Geschwindigkeit. Die komplette durchschnittsgeschwindigkeit wird aber glaub ich immer anschließend angezeigt. Beim Plattenbenchmarken immer dran denken das die Caches bis 256Mb groß sein können also mindestens ein paar GB testen.

Du bekommst einfach keine realen Lese oder Schreibgeschwidnigkeiten aus Tests die nicht erheblich größer sind als der Cache. Ich gehe davon aus das diese Verzerrung zu deiner Unsicherheit in Bezug auf die Geschwindigkeit der Kopiervorgänge geführt hat.

 

[theSplit]

Unter Windows sinds halt "nur" 16 MB die als "Durschnittsgeschwindigkeit" angezeigt werden für einen der Datenträger. Hab mich daran etwas orientiert.

Also mit anderen Worten, ruhig den Cache "puffern" lassen und einen höheren Bulksize fahren, lese ich dich richtig?

 

[alter_Bekannter]

Nicht ganz, die moral ist eher der Cache funktioniert in der Realität sehr gut, leider versaut er Testergebnisse wenn man nicht aufpasst, eben weil er gut funktioniert.

Deswegen laufen kleine Operationen trügerisch schnell und zwar fast immer. Weil die Änderungen erst mal nur im RAM der Festplatte geschehen und die Platte die echten Änderungen dann durchführt wann gerade Zeit ist. Wenn man allerdings Backups erstellt ballert man mehr drauf als so ein Cache jemals abfangen könnte, denn den so zu dimnensionieren würde keinen Sinn machen. Selbst bei Backupplatten ist der >90% use case nicht schreiben sondern Lagerung. Viel Material und Kosten für Case Schreiben zu investieren wäre also sinnlos.

Shingled Magnetic Recording Platten haben das noch extremer. 8TB Platten, Schreibgeschwindigkeit fast 200Mb pro Sekunde. für ca 500GB am Tag. Danach müssen sie die Daten für Lagerung umordnen was natürlich einen großteil der Kapazitäten aufbraucht. Festplatten sind keine dummen Geräte die sind ganze PC's, dafür wollte ich sensiblisieren. Deine Festplatte hat vermutlich mehr Rechenkapazität als ein Altair 8800 Computer. Mehr Arbeitsspeicher hat sie definitv.

Diie Firmware der Paltten ist entsprechend mittlerweile komplexer als die Betrebssysteme der 80er. Dein Computer redet mit einem Computer, er schreibt nicht auf die Festplatte, er reicht dem Computer in der Festplatte die Daten durch mit dem Auftrag sie zu speichern.

 

[theSplit]

Wäre dann die Frage, ist es sinnvoll mit dd eine höhere Bulksize anzugeben, wenn das Lesen bzw. schreiben auf X MB begrenzt ist?

Auf dem Raspberry kennt er "sync" - was soweit ich weiß alle Daten bzw. Schreibvorgänge abschließt, die noch im Cache liegen, so das man sicher "unmounten"/entfernen kann.

 

[alter_Bekannter]

Kurzfassung:
Die Rechnung enthält zu viele unbekannte Parameter für eine seriöse Antwort. Ich kenne ja nicht mal Hardware und Software deiner Festplatte.

Einfacher Weg: Testen
Alternative: siehe weiter oben.

 

[theSplit]

Soweit ich weiß, haben die 16 MB Cache, die "Intenso Memory Case(s)" - ich glaube das sollte ich dann bald feststellen bzw. heraussuchen.

Aber es bringt ja nichts 1 GB vorzuladen den ich speichern will, und denn dann aus dem RAM auf die Festplatte zu schreiben, wenn diese nicht "flush(ed)" oder "korrekt geschrieben sind", sondern "buffern" bis ans Ende der Tage.

Und dann noch mit einer Kraft von 8 bzw. 32 - damit die richtigen Blöcke geschrieben werden können.

 

[alter_Bekannter]

Also eine Festplatte in einem USB Gehäuse = Lotterie.

Da wird bekanntermaßen alles verbaut. Manchmal richtig gute Platten, manchmal der letzte Schrott aus Retouren mit "akzeptablen" SMART Werten. Was halt gerade günstig greifbar war. Daher schreibe ich auf die erstmal ein paar Hundert GB /dev/random nach dem Kauf und wenn das zu lange dauert oder die irgendwas komisches in der Zeit machen werden sie umgetauscht.

Die einfache Realität der Dinge ist in diesem Fall testen! Für gewöhnlich ist die Plattenfirmware komplett in Ordnung und tut was sie soll. Denn was anderes würde durch die vielen Tests und dem Internet schnell die Runde machen. Was die Dinger aber im Detail tun, das weiss letztlich keiner 100% sicher außer der Person die die Frimware draufgeflasht hat. Sofern diese Person im entsprechenden Assembler fit ist unds man in der Firma nicht seit 20 Jahren das "gleiche" Image auf die Platten brennt.(Was mich nicht im geringsten schockieren würde.) Ist schon irgendwie witzig. Aktuelle Technik ist in der Hardware so überdimensioniert das es in den meisten Bereichen garnicht mehr so genau sein muss. Das wiederum ist aber eigentlich nur gut. Das trifft halt auch auf Festplatten zu. Das ist aber keine großes Hackergeheimnis. Wenns dich wirklich interessiert wäre es verhältnismässig leicht herauszufinden. Zumindest erheblich detailierter als du es jetzt weisst. Aufschrauben Controller ausbauen. Und mit ein bischen Glück kannst du schnell recherchieren was das für ein Teil ist und eventuell sogar die Firmware dumpen. Das willst du aber vermutlich nicht also wirst du wohl testen müssen wie all die anderen Faulen Säcke auch.

 

[theSplit]

Ich werde mal schauen wie es damit aussieht, viel schiefgehen kann ja nicht.

Die Platten sind übrigens schon etwas älter, aber Intenso ist eigentlich eine für mich ganz passable Marke und kaputtgegangen ist bisher auch nichts davon - und die habe ich schon ein paar Jahre, aber auch halt nicht durchgängig in Betrieb.

Zur Performance, sollte eigentlich ganz ordentlich sein. Bzw. "normal". - Mein "Thunar" kopiert mit bis zu 16 MB die Sekunde, also kann ich wohl ne Bulksize von 32 MB einrichten, letzteres sollte auch dafür sorgen das die Platte gut ausgelastet werden. Ich mach das mal und messe mit "time"... dann wird man ja sehen was dabei rauskommt....

Und nein, sollte keine B-Ware sein, eigentlich, sind außerdem 2,5 Zoll Laufwerke.

--- [2017-07-22 19:50 CEST] Automatisch zusammengeführter Beitrag ---

Ich hab jetzt mal mit mehr als 32 Megabyte rumgespielt, aber 32M scheint wohl ne gute Größe zu sein für die Platten, Kopiergeschwindigkeit liegt aber dennoch bei circa 43 MB/s.

 

[Metal_Warrior]

@theSplit:

Unabhängig von der eher theoretischen Diskussion, was genau wann schneller ist, hab ich mal ne Anmerkung:

Du willst Daten kopieren. Die genaue Binärstruktur auf der Platte ist dir schnuppe. Dann nimm cp. Oder rsync. dd ist einfach instabil, weil jeder kleine Holperer auf der Platte zum Abbruch führt. Außerdem hat der normale Kopiervorgang meist den Vorteil, dass die Daten restrukturiert werden, also automatisch defragmentiert wird (ob das nun groß was raushaut oder nicht sei mal dahingestellt). Darüber hinaus hast du dann auch die Rettungsinformationen (also gelöschte Dateien etc.), die eventuell unter Datenschutz-Gesichtspunkten nicht auf die neue wandern sollten, nicht mit kopiert, was dd aber machen würde.

Ergo: dd ist dafür nicht wirklich das Tool der Wahl.

 

[drfuture]

Arg Metal.... beim Scrollen denk ich mir so *da fällt mir eine Anmerkung ein - auch wenn das Thema schon quasie geklärt ist* .... Und dann kommt die zur hälfte am Ende des Textes ;D

Je nachdem ist es ja vielleicht wichtig zu wissen ob wirklich keine Datei defekt war und die Daten vollständig übertragen wurden. Somit würde ich dann eher nicht "blind" die ganze Platte im Block kopieren.
Unter Windows nimmt man dafür robocopy - unter linux ist das Pendant dazu meines Wissens rsync - und somit für mich dann das Mittel der Wahl für solche Jobs.

 

[nik]

Der Vollständigkeit halber:

Wäre dann die Frage, ist es sinnvoll mit dd eine höhere Bulksize anzugeben, wenn das Lesen bzw. schreiben auf X MB begrenzt ist?

Absolut, der Standardwert ist so gering, dass du da einiges rausholen kannst. dd läuft hier nie ohne bs als Parameter.