ddrescue extremadamente lento en el disco duro USB

Estoy recuperando el HDD de mi computadora portátil que murió (no arrancó en absoluto, Disk Utility informó que no hubo problemas, pero no montó el disco). He conectado el HDD a través del adaptador USB. Corriendo ddrescueasí:

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

Hasta el momento no hay errores, pero la velocidad de lectura promedio se ha reducido gradualmente a 50 KB / s. Fue alrededor de 2 MB / s al principio. El tamaño de la partición es de 300 GB. Hasta ahora he podido recuperar 160GB. Me estoy recuperando a una partición HFS + en mi MacBook.

¿Cuáles podrían ser las razones de esta tasa de transferencia lenta y cómo aumentarla?

Esto parece ser solo cómo ddrescuefuncionan las transferencias USB en OSX. De este hilo titulado: Asunto: [Bug-ddrescue] ddrescue 10x lento bajo osx .

cuando se trabaja en discos duros totalmente funcionales, bajo linux realiza una velocidad de E / S completa. cuando se compila bajo osx con los indicadores de compilación predeterminados, es magnitud veces más lento, a veces se arrastra a Kb / s. el problema persiste si el archivo de salida es / dev / null.

Ese mismo hilo también tuvo esta respuesta.

En mi experiencia y pruebas en OS X, /dev/rdisk…siempre es preferible acceder a los dispositivos de caracteres sin formato. Además, la velocidad de transferencia se puede mejorar aún más configurando un tamaño de bloque de copia más grande. Un tamaño de 512 KB ( ddrescue -c 1Ki) me dio los mejores resultados en la mayoría de los casos.

Y: los dispositivos de caracteres sin formato OS X TIENEN un tamaño definido, por lo que pueden usarse fácilmente incluso en la primera ejecución. (Al menos en este punto, las notas sobre dispositivos sin formato en la documentación existente para ddrescueno se aplican a OS X.)

No creo que esto sea un error ddrescue, porque a otras utilidades les gusta ddo catexhiben el mismo comportamiento en OS X.

Acceder a un / dev / disk ... el dispositivo de bloque proporciona una velocidad bastante lenta, independiente del tamaño de bloque de copia utilizado. La velocidad de lectura de un / dev / rdisk ... el dispositivo de caracteres sin formato, por otro lado, depende mucho del tamaño de bloque de copia elegido:

• 512 Byte ( ddrescue -c 1predeterminado en dd) es el más lento.
• Establecerlo en 4096 Byte ( ddrescue -c 8, dd bs=4K) proporciona la misma velocidad lenta que acceder / dev / disk ...
• por defecto de 128 sectores (= 64KiB, de ddrecue ddrescue -c 128, dd bs=64K) trae resultados bastante buenos.
• Multiplicar eso aún más (hasta ddrescue -c 1Ki/ dd bs=512K) trae la velocidad máxima (principalmente 8-12 veces más rápido que /dev/disk…)
• El aumento por encima de eso no aumentó más la velocidad de transferencia en mis pruebas; a veces incluso disminuyó.

Esos son los resultados de mis propias mediciones, sus resultados pueden variar según los medios y el hardware IO utilizado. Tal vez si algunos otros usuarios compartieran su experiencia, podríamos obtener una mejor imagen del tema.

Referencias

• ddrescue se ha ralentizado masivamente en os x
• GNU DDrescue, ¿lo estoy haciendo bien? [tamaño de error lento / alto]

No sé mucho sobre el HFS+sistema de archivos en MacOS, sin embargo, acabo de experimentar que rescatar un disco duro interno de 500 GB (conectado a través de SATA) en una computadora portátil con Linux Mint desde un dispositivo USB, guardando la imagen de rescate y el archivo de registro en un exFatel disco duro USB formateado, comenzaba bastante lento (1-2 MB / seg) pero después de alrededor de 250 GB solo se arrastraba a <100 KB / seg. Parecía volverse más lento a medida que crecía el archivo de imagen de rescate.

Luego moví la imagen de rescate y el archivo de registro a otro lugar temporal, volví a formatear el disco duro USB con el ext4sistema de archivos, volví a colocar los archivos y reanudé el proceso ddrescue, y ahora vuelve a funcionar con 1-20 MB / seg (fluctuante pero alrededor de 7 MB / seg en promedio)

Parece exFatque no funciona muy bien con archivos muy grandes (varios cientos de gigabytes). Como ya dije, no sé si este también es el caso, HFS+pero tal vez quieras darle ext4una oportunidad.