ubuntuusers.de

Hi leute,

ich hab vor einiger Zeit ein Backup meiner 60GB IDE Notebook Festplatte gemacht, welches ich jetzt zurückspielen will. zum erstellen hab ich dd verwendet, und damit will ich das Image jetzt auch wieder auf die Platte bekommen. Ich verwende dazu folgenden Befehl:

1

dd if=/media/daten/image of=/dev/sdd bs=512

Die Partition in /media/daten liegt auf einer internen SATA-Platte, welche ca. 60MB/s daten liefert. Die IDE Platte (/dev/sdd) ist über einen USB Adapter am PC angeschlossen. Mit

1

hdparm -Tt --direct /dev/sdd

messe ich ca. 30MB/s durchsatz; was bei einer alten Platte zu erwarten war. Das kopieren mit dd dauert aber unerträglich lange. Eine kleine LED an dem USB-IDE Adapter signalisiert wenn Daten übertragen werden, da ist zu sehen dass immer ein paar Sekunden lang kopiert wird und dann für mehrere Minuten nichts passiert. Dieser Vorgang wiederholt sich ständig so dass nur einen Bruchteil der Zeit effektiv geschrieben wird. So kommt dd auf einen Durchsatz von etwa 500kb/s. Ich hab schon andere bs Werte für dd probiert; 64K, 1M, oder ganz weggelassen... Immer das selbe. währen dem Prozess verursacht dd fast 100% CPU Auslastung; das kann doch nicht normal sein.

hat jemand eine Idee was da falsch läuft? Übrigens ich habs auch schon mit ddrescue (nicht dd_rescue) versucht; das gleiche Spiel... die Platte stockt immer. Danke ☺

Mit bs=512 liest dd die Daten in 512-Byte-Häppchen, was entsprechend lange dauert. Nimm einen größeren Wert für bs.

4096=4k mindestens würde ich sagen - die gängige Blockgröße für Dateien. Er sagt aber, er habe verschiedene, größere Werte probiert.

dd ist übrigens nicht geeignet für Backups: es kopiert auch leere Blöcke z.B.

Die Zielpartition ist auch groß genug? Hm - sonst käme wohl eine Fehlermeldung (aber erst, wenn die Platte voll ist).

Wenn ich das richtig verstanden habe, dann liest dd erst bis der Puffer voll ist, schreib dann die Daten auf die Festplatte und beginnt wieder von vorne. Also macht ein relativ großer Wert für bs meiner Meinung nach Sinn. Ich nutze für gewöhnlich 8M. Damit komme ich auf allen meiner Systeme zu sehr guten Geschwindigkeiten. Wenn du damit aber schon rumprobiert hast, dann liegt es vermutlich aber nicht am Cache.

Sending a USR1 signal to a running ‘dd’ process makes it print I/O statistics to standard error and then resume copying.

Es wäre einen Versuch wert, die Statistik von dd ausgeben zu lassen. Damit lässt du das alle 60 Sekunden geschehen:

1

while [ 1 ]; do killall -USR1 dd; sleep 60; done

Du könntest auch mal die Lese- und Schreibgeschwindigkeiten der Quell- und Ziel-Devices/Dateien testen (Dass du das mit hdparm schon gemacht hast, habe ich gelesen). Lesegeschwindigkeit des Images (Zusätzlich mein Skript von oben ausführen):

dd if=/media/daten/image of=/dev/null bs=8M

Wenn auf der Zielfestplatte keine relevanten Daten sind kannst du so die reine Schreibgeschwindigkeit ermitteln. Damit wird aber der Inhalt überschrieben. Zusätzlich mein Skript von oben ausführen. Vorsicht walten lassen (Wenn du dich bei of vertippst, kannst du mitunter deine Systemfestplatte im laufenden Betrieb überschreiben):

dd if=/dev/zero of=/dev/sdd bs=8M

Damit solltest zu mit etwas Glück der Ursache einen Schritt näher gekommen sein.

user unknown schrieb:

dd ist übrigens nicht geeignet für Backups: es kopiert auch leere Blöcke z.B.

Exakt. Da sind Tools wie Partimage wesentlich besser geeignet.