Comment réparer facilement un seul bloc illisible sur un disque Linux?

22

Mon système Linux a commencé à lancer des erreurs SMART dans le syslog. Je l'ai retrouvé et je crois que le problème est un seul bloc sur le disque. Comment puis-je obtenir facilement le disque pour réallouer ce bloc? Je voudrais savoir quel fichier a été détruit au cours du processus. (Je suis conscient que si un bloc échoue sur un disque, d'autres sont susceptibles de suivre; j'ai une bonne sauvegarde en cours et je veux juste essayer de faire fonctionner ce disque.)

La recherche sur le Web mène au HOWTO Bad Block , qui décrit un processus manuel sur un disque non monté. Cela semble compliqué et sujet aux erreurs. Existe-t-il un outil pour automatiser ce processus sous Linux? Ma seule autre option est l'outil de diagnostic du fabricant , mais je présume que cela encombrera le mauvais bloc sans aucun rapport sur ce qui a été détruit. Dans le pire des cas, il peut s'agir de métadonnées de système de fichiers.

Le disque en question est la partition système principale. Utilisation d'ext3fs et LVM. Voici le journal des erreurs de syslog et le bit correspondant de smartctl.

smartd[5226]: Device: /dev/hda, 1 Currently unreadable (pending) sectors

Error 1 occurred at disk power-on lifetime: 17449 hours (727 days + 1 hours)
... Error: UNC at LBA = 0x00d39eee = 13868782

Il y a un vidage smartctl complet sur pastebin .

Nelson
la source
Je pensais que le firmware du disque remapperait automatiquement le mauvais bloc à la lecture, donc théoriquement, cela a déjà été fait. Comme indiqué ci-dessous, exécutez fsck (ou l'équiv correct pour votre FS) pour vous assurer que le FS superposé est toujours stable.
BuildTheRobots
2
Ma compréhension est que le firmware du disque ne remappera le bloc qu'en écriture , pas en lecture. Donc, vraiment, je dois forcer l'écriture sur le bloc en question.
Nelson
1
J'ai finalement retiré ce disque. Il a bien fonctionné pendant plusieurs mois, mais après la 5e erreur de lecture, j'ai abandonné.
Nelson

Réponses:

12

Tu pourrais 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é)

James
la source
Ooh, c'est un nouveau drapeau! Cela permettra certainement de réaffecter le mauvais bloc. Maintenant, tout ce dont j'ai besoin est un moyen facile de trouver ce qu'il va encombrer.
Nelson
3
Ayant utilisé cette méthode pour réparer un disque, je peux dire que c'est la bonne méthode. Forcer une écriture dans le secteur en question forcera le lecteur à faire face au secteur et soit (a) obtenir une écriture réussie, ou (b) se retrouver avec une mauvaise seconde permanente avec un remappage.
Avery Payne
Génial! Et tellement plus facile que smartmontools.sourceforge.net/badblockhowto.html
Janning
C'est étrange que ce processus itératif (de rechercher le prochain mauvais secteur via SMART et de le forcer à se
réallouer
32

J'avais l'habitude d'écrire le firmware du disque pour WD, et j'ai écrit une fois le firmware qui a réaffecté les mauvais blocs.

Premièrement, la plupart des blocs défectueux sont détectés lors des lectures et non 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 média 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 du secteur) qui est lue sur les écritures pour localiser le secteur correct, de sorte que s'il y a une erreur dans la lecture de l'en-tête du 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é.

Passons maintenant à la mauvaise réaffectation des blocs (également appelée réallocation). Oui, normalement, le lecteur tentera de réaffecter un secteur si l'erreur est suffisamment grave (c'est-à-dire que la défaillance ECC est suffisamment grave), mais le lecteur pourrait 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 effectuer 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 juste un tas de zéros, disons, puis que le secteur était relu, il retournerait 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 solution consiste donc à ne rien faire lorsque les données le peuvent. t être récupéré.

Les lecteurs modernes, cependant, enregistreront l'emplacement du secteur défectueux lorsqu'il ne peut pas être réaffecté. Le nombre de secteurs défectueux en attente de réaffectation 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éaffectation, la réaffectation est effectuée car le lecteur dispose désormais de données valides pour y écrire après la réaffectation. Ainsi, lorsque les gens disent qu'écrire dans un mauvais secteur le réaffectera, ce n'est vraiment que la moitié de l'histoire. Le lecteur doit être lu en premier 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 diront qu'il n'y a pas de mauvais secteurs 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 effacer tous les secteurs défectueux,

Il existe d'autres façons de gérer 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 autre chose que RAID 0), le logiciel RAID devrait récupérer automatiquement les données pour un secteur défectueux des autres disques et les écrire dans le secteur réaffecté. Les disques SCSI ont une commande explicite de réaffectation de blocs que l'hôte peut utiliser pour forcer la réaffectation même lorsqu'il n'y a pas de données valides à écrire dans le bloc, mais son utilisation est plutôt bas.

tenner
la source
1
Il convient également de mentionner qu'au moins certains disques durs Seagate prennent en charge la lecture-lecture-vérification, qui peut être activée à l'aide hdparm -R(en supposant un hdparm raisonnablement récent). Cela se traduit par une pénalité de performance d'écriture importante (environ la moitié du débit d'écriture et des IOPS d'écriture, car chaque écriture entraîne maintenant une lecture ultérieure), mais si votre matériel le prend en charge et que votre charge de travail est lourde en lecture, cela peut être une mesure préventive très réalisable .
un CVn
2

Je pense que tout ce que vous avez à faire est de:

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 (plus lent) non destructif. Il devra encore être démonté. Je ne pense pas que cela vous fournira des détails sur les données perdues.

Matthew Flaschen
la source
Mais c'est dommage que cela ne semble pas utiliser les informations de SMART sur les mauvais blocs. Je me demande pourquoi il n'y a pas d'outil fsck qui utiliserait les informations de blocage incorrectes de SMART et tenterait de les éviter ou de réparer les fichiers concernés comme décrit dans smartmontools.sourceforge.net/badblockhowto.html ou serverfault.com/a/106130/68972 . ..
imz - Ivan Zakharyaschev
2

Michael l'a correct et dans la plupart des cas, je dirais qu'il suffit de remplacer le lecteur, ils sont bon marché. Cependant, si vous ne disposez pas de sauvegardes et que vous ne pouvez pas obtenir de données importantes du lecteur, ou si vous voulez simplement essayer de réparer le lecteur, vous pouvez essayer d'utiliser la spinrite , au plus haut niveau.

J'avais un ordinateur portable qui a commencé à faire du bruit il y a quelques années. Badblocks a montré que le lecteur avait 118 ou plus de mauvais blocs visibles par l'utilisateur final. Comme j'avais déjà une copie de SpinRite, j'ai décidé de l'essayer avant d'acheter un nouveau lecteur. Après avoir exécuté la spinrite sur le lecteur, les badblocks ont montré 0 mauvais blocs et les bruits se sont arrêtés. Depuis, le lecteur fonctionne depuis plus de deux ans.

3dinfluence
la source
Nelson allez-vous simplement voter contre chaque réponse qui n'est pas ce que vous voulez entendre? Un disque sain remappera automatiquement un bloc défectueux. Si vous devez faire tout ce qui est en votre pouvoir pour forcer cela, le lecteur n'est plus en bonne santé et doit être remplacé.
3dinfluence
Non, je n'ai voté qu'une seule réponse parce qu'elle n'a pas répondu à ma question. Vous avez suggéré la spinrite, merci! Ma compréhension est qu'un entraînement sain ne remappera pas un mauvais secteur jusqu'à ce qu'il soit écrit. J'essaie de trouver le moyen le plus simple de forcer l'écriture. Aller à la suggestion de Matthew et voir si fsck est assez intelligent pour le faire.
Nelson
Désolé, j'ai sauté aux conclusions après avoir vu 2 réponses rejetées rapidement et vous répondez à l'autre réponse, je suppose que c'était vous.
3dinfluence
2
Vous avez raison de dire que le remappage de secteur incorrect se produit lorsqu'une écriture échoue dans un bloc. Si vous avez juste un bloc corrompu en ce qui concerne le système de fichiers, alors fsck peut régler votre problème si le bloc en question est un bloc de métadonnées. fsck scanne et corrige vraiment juste les erreurs dans les métadonnées. Il ne fait donc aucune garantie sur les données elles-mêmes. Les systèmes de fichiers de nouvelle génération tels que BTRFS et ZFS peuvent détecter et si vous avez des erreurs de données correctes de redondance. Spinrite forcerait également cela lors de la lecture, puis écrit les données inversées, relit, puis inverse les données sur chaque bloc dans le cadre de son analyse.
3dinfluence
1

Si vous avez des sauvegardes et que vous savez que c'est une erreur logique et non phisique, la meilleure façon de procéder serait de mettre à zéro le disque.

J'utiliserais MHDD, il est assez facile à utiliser et tant que vous vous souvenez de régler votre disque dur dans le BIOS sur une émulation IDE, puis de nouveau sur AHCI lorsque votre travail est terminé, vous n'avez rien à craindre.

Une fois que vous avez démarré sur MHDD, choisissez votre type de lecteur dans la commande ERASE et confirmez votre choix.

Procurez-vous du café, cela peut prendre un certain temps.

Une fois le lecteur remis à zéro, lancez l'analyse (f4) avec Remappage réglé sur ON (la valeur par défaut est désactivée). S'il y a toujours des problèmes avec le lecteur (cela signifierait qu'il y a un dommage physique sur le plateau et que le lecteur est sur une pente descendante), cette option les "réparera" en mappant la zone endommagée sur des parties saines du lecteur.

S'il n'y a aucune erreur UNC, alors félicitations, vous et votre lecteur pouvez toujours être amis pour les années à venir.

Jahith
la source
-1

Si le disque va mal, remplacez-le. Cela ne vaut pas le risque qu'il s'effondre davantage.

Michael Graff
la source
J'étais explicite de savoir que le disque est mauvais et d'avoir des sauvegardes pour éviter le risque.
Nelson
2
Cela signifie simplement que vous êtes prêt à jouer. Je ne pense pas que cela signifie qu'il ne devrait pas être remplacé, juste que vous êtes prêt à ignorer ce conseil. Je doute que toutes les sauvegardes puissent sauver votre système de lui-même lorsque le disque se désagrège, et les choses deviendront très instables à mesure que les choses se dégradent.
Michael Graff
3
Cette réponse devrait être un commentaire ... La question est spécifique et exaustive. Et donc ce n'est pas une réponse.
Pitto