ddrescue extremamente lento no disco rígido USB

Question

Estou recuperando o HDD do meu laptop que morreu (não inicializaria, o Utilitário de Disco relatou que não havia problemas, mas não montaria o disco). Eu conectei o HDD através do adaptador USB. Executando ddrescue da seguinte forma:

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

Não há erros até agora, mas a velocidade média de leitura caiu gradualmente para 50KB / s. Foi em torno de 2MB / s no começo. O tamanho da partição é de 300 GB. Até agora eu consegui recuperar 160GB. Estou me recuperando para uma partição HFS + no meu MacBook.

Quais poderiam ser as razões para essa baixa taxa de transferência e como aumentá-la?

    

Answer 1

Isso parece ser apenas como ddrescue & As transferências USB funcionam no OSX. A partir deste tópico intitulado: Assunto: [Bug-ddrescue] ddrescue 10x lento sob osx .

when working on fully functional hard drives, under linux it performs full i/o speed. when compiled under osx with the default compile flags, it is magnitude times slower, sometimes crawling to Kb/s. the problem persists if the output file is /dev/null.

Esse mesmo segmento também teve essa resposta.

In my experience and testing on OS X, accessing the raw character devices /dev/rdisk… is always preferable. Also the transfer speed can be further enhanced by setting a bigger Copy Block Size. A size of 512KiB (ddrescue -c 1Ki) gave me the best results in most cases.

And: OS X raw character devices DO have a defined size, so they can be easily used even in the first run. (At least in this point the notes about raw devices in the existing documentation for ddrescue do not apply to OS X.)

I don't think this is a bug in ddrescue, because other utilities like dd or cat exhibit the same behavior on OS X.

Accessing a /dev/disk… block device gives a rather slow speed, independent of the Copy Block Size used. The reading speed of a /dev/rdisk… raw character device on the other hand depends a lot on the Copy Block Size chosen:

• 512 Byte (ddrescue -c 1, default in dd) is the slowest.
• Setting it to 4096 Byte (ddrescue -c 8, dd bs=4K) gives the same slow speed as accessing /dev/disk…
• ddrecue's default of 128 sectors (= 64KiB, ddrescue -c 128, dd bs=64K) brings fairly good results.
• Multiplying that further (up to ddrescue -c 1Ki / dd bs=512K) brings maximum speed (mostly 8-12 times faster than /dev/disk…)
• Rising above that did not increase transfer speed any further in my testing; sometimes it even decreased.

Those are the results of my own measurements, your results may vary depending on the media and IO hardware used. Maybe if some other users would share their experience, we could gain a better picture of the topic.

Referências

• O ddrescue abrandou massivamente no os x
• GNU DDrescue, estou fazendo certo? [tamanho do erro lento / alto]

Answer 2

Eu não sei muito sobre o sistema de arquivos HFS+ no MacOS, no entanto, acabei de fazer a experiência de resgatar um disco rígido interno de 500GB (conectado via SATA) em um laptop executando o Linux Mint a partir de um pendrive USB. imagem de salvamento e arquivo de log em um disco rígido USB exFat formatado, estava começando bem devagar (1-2 MB / s), mas depois de cerca de 250 GB ele estava rastreando apenas a < 100 KB / s. Parecia ficar mais lento quanto maior o arquivo de imagem de resgate estava crescendo.

Em seguida, movi a imagem de resgate e o arquivo de log para outro local temporário, reformatei o disco rígido USB com o sistema de arquivos ext4 , movi os arquivos de volta e retomei o processo do ddrescue - e agora ele é executado com 1 20MB / seg novamente (flutuando mas em média 7MB / seg)!

Parece que exFat não funciona muito bem com arquivos muito grandes (várias centenas de gigabytes). Como já disse, não sei se esse também é o caso de HFS+ , mas talvez você queira dar ext4 de chance.