Bonjour à tous.
A) Mon impression générale qui reste à confirmer.
. Ce n'est probablement pas le disque qui est si démagnétisé que cela. J'en déduis que c'est la tête de lecture qui est nase.....
Autant arrêter les frais maintenant.
B) Je vais donner le paramétrage pour sauter les 80 premiers GO.
je ne l'ai encore jamais utilisé... j'espère faire une bonne codification.
C) Même si le chkdsk a mis la structure en vrac, ddrescue s'en moque, il copie chaque secteur sans regarder sa logique. Ce n'est que plus tard après la fin de ddrescue qu'on retente de remettre en structure logique. Vu le début catastrophique de ce début de copie, J'ai déjà évoqué que cela risque de ne pas être possible et que la suite va se passer avec photorec qui lit le contenu de chaque secteur et essaie d'identifier ce qu'il peut y avoir dedans. Dans un tel contexte, il n'y a plus de nom de fichier possible.
D) Pour le paramétrage
-i, --input-position=<bytes> starting position of domain in input file [0]
-o, --output-position=<bytes> starting position in output file [ipos]
Si vous êtes d'accord, je suggère qu'on stoppe le ddrescue actuellement en cours,
que tu donnes le résultat
puis que je donnes la commande pour dupliquer la portion de fichier actuellement sauvée au cas ou par la suite on pourrait reprendre.
Ou alors on fait l'impasse sur ce sauvetage. (ce que je pense)
La nouvelle commande sera
sudo ddrescue -f -n -b4096 -i85899345590 /dev/sda5 /dev/sdd2 /mnt/dd/suivi
80*1024*1024*1024=85899345590
et devrait parfaitement fonctionner sans indiquer la position de sortie si j'en crois mon test.
u16041@u16041:~$ sudo ddrescue -f -n -b4096 -i8589934559 /dev/sda6 /dev/null
GNU ddrescue 1.19
Press Ctrl-C to interrupt
rescued: 419495 kB, errsize: 0 B, current rate: 88473 kB/s
ipos: 9009 MB, errors: 0, average rate: 83899 kB/s
opos: 9009 MB, run time: 5 s, successful read: 0 s ago
Copying non-tried blocks... Pass 1 (forwards)^C
Interrupted by user
Si le comportement est identique, cela sera la confirmation que soit la tête est nase ou que le disque est entièrement démagnétisé.
Dans les deux cas, c'est fichu. La réparation en laboratoire spécialisé sera d'environ 1000 €. Dans l'ensemble, ils ne facturent que s'ils disent avoir réussi.
E) J'ai repris cette commande
xubuntu@xubuntu:~$ dmesg | grep -Ei "print_req_error" | tail -100
[48058.376134] print_req_error: I/O error, dev sda, sector 9868944
Erreur sur le secteur 9868944, donc le logiciel saute 128 secteurs par principe ( paramétrable) sachant que lorsque la fin du disque sera atteinte, il reviendra copier cette partie sautée.
Il part du principe que, si un secteur est illisible, il y a de forte chance que le suivant le soit aussi. Pour faire une copie rapide, il fait une impasse de 64 Ko (paramétrable) afin d'aller vite et de ne pas faire d'user sur ces endroits
donc le secteur suivant qui sera lu sera 9868944+128= 9869072
[48062.132170] print_req_error: I/O error, dev sda, sector 9877400
[48065.676178] print_req_error: I/O error, dev sda, sector 9877400
donc, il a lu 768 secteurs avant de retrouver un problème. La trace de moko a montré que le firmware voulait le dupliquer et
on ne sait plus l'empêcher de le faire.
Je n'ose imaginer le temps que cela va prendre pour les 127 secteurs qui suivent le secteur 9868944 sachant qu'il est certain que les 7 suivants ne seront pas lisibles.
(512+7*512=4096)
[48070.364196] print_req_error: I/O error, dev sda, sector 9877792
[48073.908099] print_req_error: I/O error, dev sda, sector 9877792
9877792+128= 9877920
[48077.452002] print_req_error: I/O error, dev sda, sector 9878016
Donc ici seulement 96 secteurs de sauvés en réalité!!
[48081.140373] print_req_error: I/O error, dev sda, sector 9878448
[48084.764091] print_req_error: I/O error, dev sda, sector 9878448
Je suis désolé, mais je vais m'absenter une grande partie de la journée.
