ddrescue extremadamente lento en el disco duro USB

9

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?

osx usb hard-disk ddrescue Mik
fuente

Respuestas:

8

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

slm
fuente
1
Cambiar el tamaño del bloque de copia no afecta la velocidad de transferencia en mi caso. Sin embargo, jugando con / dev / null pude obtener una buena velocidad de transferencia (hasta 8 MB / s) al configurar la posición del archivo de entrada en 200 GB. Ahora he reanudado mi proceso de restauración con parámetros adicionales -i214748364800. Espero que los 0 a 160 GB iniciales no se vean afectados por esto.
Mik
1
Lamentablemente, el aumento en la tasa de transferencia fue de corta duración. Intentaré correr ddrescuedesde el sistema unix.
Mik
Experiencia compartida: tasas de ddrescue bajas (~ 20,000 kB / s) con contenido ZFS en un buen disco, USB 3.0 limitado a USB 2.0 con un MacBookPro5,2 2009
Graham Perrin
@Mik Gracias por dar el parámetro exacto que usó para reanudar la recuperación en una posición diferente. La unidad de origen había fallado en la posición 121242584064 e intenté reanudarla, pero ddrescue dijo Error de lectura no alineado. ¿Es correcto el tamaño del sector? Entonces, usando su valor, reanudé a 200GB. Y no, no afecta los 0 - 160GB iniciales.
Colin
0

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.

Puñal
fuente