ddrescue estremamente lento sul disco rigido USB

Sto recuperando l'HDD dal mio laptop che è morto (non si avvia affatto, Utility Disco ha riferito che non c'erano problemi, ma non montava il disco). Ho collegato l'HDD tramite l'adattatore USB. Funzionando ddrescuecosì:

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

Finora non ci sono errori, ma la velocità di lettura media è gradualmente scesa a 50 KB / s. All'inizio erano circa 2 MB / s. La dimensione della partizione è di 300 GB. Finora sono riuscito a recuperare 160 GB. Sto recuperando in una partizione HFS + sul mio MacBook.

Quali potrebbero essere le ragioni di questa velocità di trasferimento lenta e come aumentarla?

Questo sembrerebbe essere il modo in cui i ddrescuetrasferimenti USB funzionano sotto OSX. Da questa discussione intitolata: Oggetto: [Bug-ddrescue] ddrescue 10x lento sotto osx .

quando si lavora su dischi rigidi perfettamente funzionanti, con Linux esegue la massima velocità di I / O. quando compilato sotto osx con i flag di compilazione predefiniti, è magnitudo volte più lento, a volte strisciando a Kb / s. il problema persiste se il file di output è / dev / null.

Lo stesso thread ha avuto anche questa risposta.

Nella mia esperienza e test su OS X, /dev/rdisk…è sempre preferibile accedere ai dispositivi con caratteri non elaborati. Inoltre, la velocità di trasferimento può essere ulteriormente migliorata impostando una dimensione del blocco copia maggiore. Una dimensione di 512 KiB ( ddrescue -c 1Ki) mi ha dato i migliori risultati nella maggior parte dei casi.

Inoltre: i dispositivi con caratteri non elaborati OS X hanno una dimensione definita, quindi possono essere facilmente utilizzati anche al primo avvio. (Almeno a questo punto le note sui dispositivi grezzi nella documentazione esistente ddrescuenon si applicano a OS X.)

Non penso che questo sia un bug ddrescue, perché ad altre utility piace ddo catmostra lo stesso comportamento su OS X.

L'accesso a un dispositivo a blocchi / dev / disk ... offre una velocità piuttosto lenta, indipendentemente dalla dimensione del blocco copia utilizzata. La velocità di lettura di un dispositivo a caratteri / dev / rdisk… raw, d'altra parte, dipende molto dalla dimensione del blocco di copia scelta:

• 512 byte ( ddrescue -c 1, predefinito in dd) è il più lento.
• Impostandolo su 4096 byte ( ddrescue -c 8, dd bs=4K) si ottiene la stessa velocità lenta dell'accesso a / dev / disk ...
• predefinito di ddrecue di 128 settori (= 64KiB, ddrescue -c 128, dd bs=64K) porta discreti risultati.
• Moltiplicando ulteriormente (fino a ddrescue -c 1Ki/ dd bs=512K) si ottiene la massima velocità (per lo più 8-12 volte più veloce di /dev/disk…)
• Al di sopra di ciò che non ha aumentato ulteriormente la velocità di trasferimento nei miei test; a volte è persino diminuito.

Questi sono i risultati delle mie misurazioni, i tuoi risultati possono variare a seconda del supporto e dell'hardware IO utilizzato. Forse se alcuni altri utenti condividessero la loro esperienza, potremmo ottenere una migliore immagine dell'argomento.

Riferimenti

• ddrescue ha subito un forte rallentamento su os x
• GNU DDrescue, lo sto facendo bene? [dimensione errore lenta / alta]

Non so molto del HFS+file system su MacOS, tuttavia, ho appena fatto l'esperienza del salvataggio di un disco rigido interno da 500 GB (collegato tramite SATA) su un laptop con Linux Mint da una chiavetta USB, salvando l'immagine di salvataggio e il file di log su un exFatdisco rigido USB formattato, si avviava piuttosto lentamente (1-2 MB / sec), ma dopo circa 250 GB si spostava solo a <100 KB / sec. Sembrava rallentare quanto più cresceva il file di immagine di salvataggio.

Quindi ho spostato l'immagine di salvataggio e il file di registro in un altro posto temporaneo, ho riformattato il disco rigido USB con il ext4file system, ho spostato i file su di esso e ho ripreso il processo ddrescue - e ora funziona di nuovo con 1-20 MB / sec (fluttuante ma circa 7 MB / sec in media)!

Sembra exFatche non funzioni molto bene con file molto grandi (diverse centinaia di gigabyte). Come già detto, non so se questo sia anche il caso, HFS+ma forse vuoi provare ext4.