Solution 1 :
J'avais l'habitude d'écrire le firmware du disque pour WD, et j'ai écrit une fois le firmware qui réaffectait les blocs défectueux.
Premièrement, la plupart des blocs défectueux sont détectés lors des lectures, pas des écritures. Les écritures sont effectuées à l'aveugle, ce qui signifie que les données sont écrites sans être vérifiées. Ainsi, lors d'une écriture, si le support est mauvais, vous ne le saurez pas tant que l'hôte n'aura pas lu ce secteur. Il y a une petite partie du secteur (l'en-tête de secteur) qui est lue lors des écritures pour localiser le secteur correct, de sorte que s'il y a une erreur dans la lecture de l'en-tête de secteur, le lecteur réaffectera le secteur et l'écrira avec les données reçues à partir de la commande d'écriture. Mais la grande majorité des blocs défectueux sont détectés lors des lectures, et ce n'est pas parce qu'une écriture réussit dans un secteur que le média est bon ou que le secteur a été réaffecté.
Parlons maintenant de la mauvaise réaffectation des blocs (également appelée réaffectation). Oui, normalement, le lecteur tentera de réaffecter un secteur si l'erreur est suffisamment grave (c'est-à-dire que l'échec ECC est suffisamment grave), mais le lecteur peut toujours récupérer les données après la correction ECC. Habituellement, cela se fait automatiquement. La seule exception est que l'hôte aurait pu auparavant dire au lecteur de ne pas faire de réallocations automatiques, mais cela est rarement fait.
Que se passe-t-il si le lecteur effectue une lecture et ne peut pas récupérer les données ? Rien. L'erreur est signalée à l'hôte, mais aucune réaffectation n'est effectuée. Le problème est que le lecteur pourrait réaffecter le secteur, mais il n'a pas la moindre idée des données à écrire dans le secteur nouvellement réaffecté. S'il écrivait simplement un tas de zéros, par exemple, puis que le secteur était lu à nouveau, il renverrait tous les zéros sans aucune indication que les données n'étaient pas valides. C'est essentiellement la même chose que la corruption de données. Le lecteur ne peut pas compter sur l'hôte pour garder une trace des erreurs pour diverses raisons (par exemple, que se passe-t-il si le lecteur a été déplacé vers un nouvel hôte ?), la meilleure chose à faire est donc de ne rien faire lorsque les données peuvent ' ne pas être récupéré.
Les lecteurs modernes, cependant, enregistreront l'emplacement du secteur défectueux lorsqu'il ne pourra pas être réaffecté. Le nombre de secteurs défectueux en attente de réallocation peut être trouvé dans les données SMART. Ce qui se passe, c'est que si une écriture est effectuée sur l'un des secteurs défectueux en attente de réallocation, la réallocation est effectuée car le lecteur dispose désormais de données valides à écrire après la réallocation. Ainsi, lorsque les gens disent qu'écrire dans un secteur défectueux le réaffectera, ce n'est vraiment que la moitié de l'histoire. Le lecteur doit d'abord être lu afin que le lecteur puisse découvrir tous les secteurs défectueux qui ne peuvent pas être réaffectés automatiquement. Ainsi, vous pouvez écrire un lecteur entier, et les données SMART indiqueront qu'il n'y a pas de secteurs défectueux en attente de réaffectation, mais vous n'avez pas nécessairement effacé le lecteur de tous les secteurs défectueux. Donc, si vous voulez vraiment nettoyer un lecteur de tous les secteurs défectueux, la meilleure chose à faire est de lire d'abord l'intégralité du lecteur, puis d'écrire l'intégralité du lecteur (bien sûr, cela détruira toutes les données précédentes sur le lecteur).
Il existe d'autres façons de traiter les blocs défectueux qui ne peuvent pas être réaffectés. Si le disque fait partie d'une configuration RAID redondante (c'est-à-dire tout sauf RAID 0), le logiciel RAID doit automatiquement récupérer les données d'un secteur défectueux à partir des autres disques et les écrire dans le secteur réaffecté. Les disques SCSI ont une commande explicite de réaffectation des blocs que l'hôte peut utiliser pour forcer la réaffectation même s'il n'y a pas de données valides à écrire sur le bloc, mais son utilisation est assez basique.
Solution 2 :
Vous pouvez essayer hdparm --write-sector <LBA> /dev/ice .
Je ne connais pas d'autre moyen de le faire - vous devez convertir manuellement le LBA en blocs de système de fichiers (comme vous l'avez déjà trouvé)
Solution 3 :
Je pense que tout ce que vous avez à faire est :
e2fsck -c /dev/hda1
en supposant que /dev/hda1 est la partition (non montée). Ou :
e2fsck -c -c /dev/hda1
pour effectuer un test de lecture-écriture non destructif (plus lent). Il faudra encore le démonter. Je ne pense pas que cela vous donnera des détails sur les données perdues, cependant.
Solution 4 :
Michael a raison et dans la plupart des cas, je dirais qu'il suffit de remplacer le lecteur, ils sont bon marché. Cependant, si vous n'avez pas de sauvegardes et que vous ne pouvez pas extraire des données importantes du lecteur, ou si vous souhaitez simplement tenter de réparer le lecteur, vous pouvez essayer d'utiliser spinrite, au niveau le plus élevé.
J'avais un lecteur d'ordinateur portable qui a commencé à faire du bruit il y a quelques années. Badblocks a montré que le lecteur avait environ 118 blocs défectueux visibles pour l'utilisateur final. Comme j'avais déjà une copie de SpinRite, j'ai décidé de l'essayer avant d'acheter un nouveau disque. Après avoir exécuté spinrite sur le lecteur, les badblocks ont montré 0 blocs défectueux et les bruits se sont arrêtés. Depuis lors, le lecteur fonctionnait depuis plus de deux ans.