ddrescue extrem langsam auf USB-Festplatte

Ich stelle die Festplatte von meinem Laptop wieder her, der gestorben ist (würde überhaupt nicht hochfahren, das Festplatten-Dienstprogramm hat gemeldet, dass es keine Probleme gab, aber die Festplatte nicht gemountet). Ich habe die Festplatte über den USB-Adapter angeschlossen. Laufen ddrescuewie folgt:

sudo ddrescue -v -n /dev/disk1s2 "/Volumes/Original HD/image.dmg" ddrescue.log

Bisher gibt es keine Fehler, aber die durchschnittliche Lesegeschwindigkeit ist allmählich auf 50 KB / s gesunken. Am Anfang waren es ungefähr 2 MB / s. Die Größe der Partition beträgt 300 GB. Bisher konnte ich 160 GB wiederherstellen. Ich stelle eine HFS + -Partition auf meinem MacBook wieder her.

Was könnten die Gründe für diese langsame Übertragungsrate sein und wie kann sie erhöht werden?

— Mik
quelle

Dies scheint genau so zu sein, wie ddrescue& USB-Übertragungen unter OSX funktionieren. Aus diesem Thread mit dem Titel: Betreff: [Bug-ddrescue] ddrescue 10x langsam unter osx .

Wenn Sie auf voll funktionsfähigen Festplatten arbeiten, wird unter Linux die volle E / A-Geschwindigkeit ausgeführt. Wenn es unter osx mit den Standard-Kompilierungsflags kompiliert wird, ist es um ein Vielfaches langsamer und kriecht manchmal auf Kb / s. Das Problem besteht weiterhin, wenn die Ausgabedatei / dev / null ist.

Der gleiche Thread hatte auch diese Antwort.

Nach meiner Erfahrung und beim Testen unter OS X ist der Zugriff auf die Raw-Character-Geräte /dev/rdisk…immer vorzuziehen. Auch die Übertragungsgeschwindigkeit kann durch Einstellen einer größeren Kopierblockgröße weiter verbessert werden. Eine Größe von 512 KB ( ddrescue -c 1Ki) ergab in den meisten Fällen die besten Ergebnisse.

Und: OS X-Rohzeichengeräte haben eine definierte Größe, sodass sie bereits im ersten Durchgang problemlos verwendet werden können. (Zumindest in diesem Punkt gelten die Hinweise zu Raw-Geräten in der vorhandenen Dokumentation für ddrescuenicht für OS X.)

Ich denke nicht, dass dies ein Fehler ist ddrescue, da andere Dienstprogramme unter OS X das gleiche Verhalten mögen ddoder catzeigen.

Der Zugriff auf ein / dev / disk… -Blockgerät bietet eine relativ langsame Geschwindigkeit, unabhängig von der verwendeten Kopierblockgröße. Die Lesegeschwindigkeit eines / dev / rdisk… Rohzeichengeräts hängt dagegen stark von der gewählten Kopierblockgröße ab:

512 Byte ( ddrescue -c 1Standardeinstellung in dd) ist das langsamste.

Wenn Sie den Wert auf 4096 Byte ( ddrescue -c 8, dd bs=4K) setzen, ist die Geschwindigkeit genauso langsam wie beim Zugriff auf / dev / disk…

Der Standardwert von ddrecue von 128 Sektoren (= 64 KB ddrescue -c 128, dd bs=64K) bringt ziemlich gute Ergebnisse.

Eine weitere Multiplikation (bis zu ddrescue -c 1Ki/ dd bs=512K) bringt maximale Geschwindigkeit (meist 8-12 mal schneller als /dev/disk…)

Ein Anstieg darüber erhöhte die Übertragungsgeschwindigkeit in meinen Tests nicht weiter. manchmal nahm es sogar ab.

Dies sind die Ergebnisse meiner eigenen Messungen. Ihre Ergebnisse können je nach verwendetem Medium und verwendeter E / A-Hardware variieren. Wenn einige andere Benutzer ihre Erfahrungen teilen würden, könnten wir uns vielleicht ein besseres Bild von dem Thema machen.

Verweise

— slm
quelle

Das Ändern der Größe des Kopierblocks wirkt sich in meinem Fall nicht auf die Übertragungsgeschwindigkeit aus. Beim Spielen mit / dev / null konnte ich jedoch eine gute Übertragungsrate (bis zu 8 MB / s) erzielen, indem ich die Position der Eingabedatei auf 200 GB setzte. Ich habe jetzt meinen Wiederherstellungsprozess mit zusätzlichen Parametern fortgesetzt -i214748364800. Ich hoffe, dass die anfänglichen 0 - 160 GB davon nicht betroffen sind.

— Mik

Leider war die Erhöhung der Übertragungsrate nur von kurzer Dauer. Ich werde versuchen, ddrescuevom Unix-System zu laufen .

— Mik

Gemeinsame Erfahrung: Ddrescue-Raten niedrig (~ 20.000 kB / s) mit ZFS-Inhalten auf einem guten Laufwerk, USB 3.0 auf USB 2.0 mit einem 2009 MacBookPro5,2 beschränkt

— Graham Perrin

@Mik Vielen Dank, dass Sie den genauen Parameter angegeben haben, mit dem Sie die Wiederherstellung an einer anderen Position fortgesetzt haben. Das Quelllaufwerk, an dem ich an Position 121242584064 ausgefallen war, und ich habe versucht, es fortzusetzen, aber ddrescue hat den Fehler "Unaligned read" gemeldet. Ist die Sektorgröße korrekt? Also habe ich mit Ihrem Wert bei 200 GB weitergemacht. Und nein, die anfänglichen 0 - 160 GB sind davon nicht betroffen.

— Colin

Ich weiß nicht viel über das HFS+Dateisystem unter MacOS, habe jedoch gerade die Erfahrung gemacht, dass eine interne 500-GB-Festplatte (über SATA verbunden) auf einem Laptop mit Linux Mint von einem USB-Stick gerettet und das Rettungsimage und die Protokolldatei auf einem gespeichert werden exFatDie formatierte USB-Festplatte startete ziemlich langsam (1-2 MB / s), krabbelte jedoch nach etwa 250 GB nur mit <100 KB / s. Es schien langsamer zu werden, je größer die Rettungsbilddatei wurde.

Dann habe ich das Rettungsimage und die Protokolldatei an einen anderen temporären Ort verschoben, die USB-Festplatte mit dem ext4Dateisystem neu formatiert , die Dateien wieder darauf verschoben und den Ddrescue-Prozess fortgesetzt - und jetzt läuft es wieder mit 1-20 MB / s (schwankend) aber durchschnittlich etwa 7 MB / s)!

Scheint exFatnicht sehr gut mit sehr großen Dateien (mehrere hundert Gigabyte) zu spielen. Wie bereits gesagt, weiß ich nicht, ob dies auch der Fall ist, HFS+aber vielleicht möchten Sie es versuchen ext4.

— Dolch
quelle