ddrescue extrêmement lent sur le disque dur USB

Je récupère le disque dur de mon ordinateur portable mort (ne démarre pas du tout, l'Utilitaire de disque a signalé qu'il n'y avait aucun problème, mais ne montait pas le disque). J'ai branché le disque dur via l'adaptateur USB. Courir ddrescuecomme ça:

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

Il n'y a pas d'erreurs jusqu'à présent, mais la vitesse de lecture moyenne a progressivement chuté à 50 Ko / s. Il était d'environ 2 Mo / s au début. La taille de la partition est de 300 Go. Jusqu'à présent, j'ai pu récupérer 160 Go. Je récupère sur une partition HFS + sur mon MacBook.

Quelles pourraient être les raisons de ce lent taux de transfert et comment l'augmenter?

— Mik
source

Cela semblerait être juste la façon dont ddrescueles transferts USB fonctionnent sous OSX. De ce fil intitulé: Objet: [Bug-ddrescue] ddrescue 10x lent sous osx .

lorsque vous travaillez sur des disques durs entièrement fonctionnels, sous linux, il offre une vitesse d'E / S complète. lorsqu'il est compilé sous osx avec les drapeaux de compilation par défaut, il est plus lent fois en magnitude, parfois en rampant jusqu'à Kb / s. le problème persiste si le fichier de sortie est / dev / null.

Ce même fil a également eu cette réponse.

D'après mon expérience et mes tests sur OS X, l'accès aux périphériques de caractères bruts /dev/rdisk…est toujours préférable. La vitesse de transfert peut également être encore améliorée en définissant une taille de bloc de copie plus grande. Une taille de 512 Ko ( ddrescue -c 1Ki) m'a donné les meilleurs résultats dans la plupart des cas.

Et: les périphériques de caractères bruts OS X ont une taille définie, de sorte qu'ils peuvent être facilement utilisés même lors de la première exécution. (Au moins à ce stade, les notes sur les périphériques bruts dans la documentation existante pour ddrescuene s'appliquent pas à OS X.)

Je ne pense pas que ce soit un bug ddrescue, car d'autres utilitaires aiment ddou catprésentent le même comportement sur OS X.

L'accès à un périphérique de bloc / dev / disk… donne une vitesse plutôt lente, indépendamment de la taille de bloc de copie utilisée. La vitesse de lecture d'un / dev / rdisk… périphérique de caractères bruts d'autre part dépend beaucoup de la taille de bloc de copie choisie:

512 octets ( ddrescue -c 1par défaut dd) est le plus lent.

La définition de 4096 octets ( ddrescue -c 8, dd bs=4K) donne la même vitesse lente que l'accès à / dev / disk…

par défaut de ddrecue de 128 secteurs (= 64 Kio, ddrescue -c 128, dd bs=64K) donne des résultats assez bons.

Multipliant cela (jusqu'à ddrescue -c 1Ki/ dd bs=512K) apporte une vitesse maximale (généralement 8-12 fois plus rapide que /dev/disk…)

S'élever au-dessus de cela n'a pas augmenté la vitesse de transfert dans mes tests; parfois, il a même diminué.

Ce sont les résultats de mes propres mesures, vos résultats peuvent varier en fonction du support et du matériel IO utilisé. Peut-être que si d'autres utilisateurs partageaient leur expérience, nous pourrions avoir une meilleure image du sujet.

Références

— slm
source

Changer la taille du bloc de copie n'affecte pas la vitesse de transfert dans mon cas. Cependant, en jouant avec / dev / null, j'ai pu obtenir un bon taux de transfert (jusqu'à 8 Mo / s) en définissant la position du fichier d'entrée sur 200 Go. J'ai maintenant repris mon processus de restauration avec des paramètres supplémentaires -i214748364800. J'espère que le 0-160 Go initial ne sera pas affecté par cela.

— Mik

Malheureusement, l'augmentation du taux de transfert a été de courte durée. J'essaierai de courir à ddrescuepartir du système unix.

— Mik

Expérience partagée: taux de secours bas (~ 20 000 kB / s) avec du contenu ZFS sur un bon disque, USB 3.0 limité à USB 2.0 avec un MacBookPro5,2 2009

— Graham Perrin

@Mik Merci d'avoir donné le paramètre exact que vous avez utilisé pour reprendre la récupération à une position différente. Le lecteur source que j'avais échoué à la position 121242584064 et j'ai essayé de le dépasser, mais ddrescue a dit une erreur de lecture non alignée. La taille du secteur est-elle correcte? Donc, en utilisant votre valeur, j'ai repris à 200 Go. Et non, cela n'affecte pas le 0-160 Go initial.

— Colin

Je ne connais pas grand-chose au HFS+système de fichiers sur MacOS, cependant, je viens de faire l'expérience que le sauvetage d'un disque dur interne de 500 Go (connecté via SATA) sur un ordinateur portable exécutant Linux Mint à partir d'une clé USB, enregistre l'image de secours et le fichier journal sur un exFatdisque dur USB formaté, démarre assez lentement (1-2 Mo / sec) mais après environ 250 Go, il ne fait que ramper à <100 Ko / sec. Il semblait devenir plus lent à mesure que le fichier image de sauvetage augmentait.

Ensuite, j'ai déplacé l'image de secours et le fichier journal vers un autre endroit temporaire, reformaté le disque dur USB avec le ext4système de fichiers, replacé les fichiers dessus et repris le processus ddrescue - et maintenant il fonctionne à nouveau avec 1-20 Mo / sec (fluctuant mais environ 7 Mo / sec en moyenne)!

On dirait exFatque ne joue pas très bien avec de très gros fichiers (plusieurs centaines de gigaoctets). Comme déjà dit, je ne sais pas si c'est aussi le cas HFS+mais peut-être voulez-vous donner ext4un coup de feu.

— Poignard
source