Un secteur illisible en attente est un secteur qui a renvoyé une erreur de lecture et que le lecteur a marqué pour remappage à la première occasion possible. Cependant, il ne peut pas effectuer le remappage tant que l'une des deux choses suivantes ne se produit pas :
- Le secteur est relu avec succès
- Le secteur est réécrit
D'ici là, le secteur reste en suspens. Vous avez donc deux manières correspondantes de gérer cela :
- Continuez d'essayer de relire le secteur jusqu'à ce que vous réussissiez
- Remplacer ce secteur par de nouvelles données
De toute évidence, (1) est non destructif, vous devriez donc probablement l'essayer en premier, mais gardez à l'esprit que si le lecteur commence à tomber en panne de manière grave, la lecture continue d'une zone défectueuse risque de le faire échouer beaucoup plus rapidement. . Si vous avez beaucoup de secteurs en attente et d'autres erreurs, et que vous vous souciez des données sur le disque, je vous recommande de le mettre hors service et d'utiliser l'excellent outil ddrescue pour récupérer autant de données que possible. Jetez ensuite le lecteur.
Si le secteur en question contient des données dont vous ne vous souciez pas ou que vous pouvez restaurer à partir d'une sauvegarde, l'écraser est probablement la solution la plus rapide et la plus simple. Vous pouvez ensuite afficher les comptes réaffectés et en attente pour le lecteur afin de vous assurer que le secteur a été pris en charge.
Comment savoir à quoi correspond le secteur dans le système de fichiers ? J'ai trouvé un excellent article sur les smartmontools site web, ici, bien qu'il soit assez technique et spécifique aux systèmes de fichiers ext2/3/4 et reiser.
Une approche plus simple, que j'ai utilisée sur l'un de mes propres lecteurs (Mac), consiste à utiliser find / -xdev -type f -print0 | xargs -0 ... pour lire tous les fichiers du système. Notez le décompte en attente avant de l'exécuter. Si le secteur est à l'intérieur d'un fichier, vous obtiendrez un message d'erreur de l'outil que vous avez utilisé pour lire les fichiers (par exemple md5sum) vous indiquant le chemin d'accès. Vous pouvez alors concentrer votre attention sur la relecture de ce fichier jusqu'à ce qu'il soit lu avec succès. Souvent, cela résoudra le problème, s'il s'agit d'un fichier peu utilisé qui a juste besoin d'être relu plusieurs fois. Si l'erreur disparaît ou si vous ne rencontrez aucune erreur lors de la lecture de tous les fichiers, vérifiez le nombre d'attentes pour voir s'il a diminué. Si c'est le cas, le problème a été résolu en lisant.
Si le fichier ne peut pas être lu avec succès après plusieurs tentatives (par exemple 20), vous devez écraser le fichier, ou le bloc dans le fichier, pour permettre au lecteur de réattribuer le secteur. Vous pouvez utiliser ddrescue sur le fichier (plutôt que sur la partition) pour écraser un seul secteur, en le copiant dans un fichier temporaire, puis en le copiant à nouveau. Notez que le simple fait de supprimer le fichier à ce stade est une mauvaise idée, car le secteur défectueux ira dans la liste libre où il sera plus difficile à trouver. L'écraser complètement est également mauvais, car encore une fois, les secteurs iront dans la liste libre. Vous devez réécrire les blocs existants. Le notrunc possibilité de dd est une façon de le faire.
Si vous ne rencontrez aucune erreur et que le nombre d'attentes n'a pas diminué, le secteur doit se trouver dans la liste libre ou dans une partie de l'infrastructure du système de fichiers (par exemple une table d'inodes). Vous pouvez essayer de remplir tout l'espace libre avec cat /dev/zero >tempfile , puis vérifiez le décompte en attente. S'il tombe en panne, le problème était dans la liste gratuite et a maintenant disparu.
Si le secteur se trouve dans l'infrastructure, vous avez un problème plus grave et vous rencontrerez probablement des erreurs en parcourant l'arborescence des répertoires. Dans cette situation, je pense que la seule solution sensée est de reformater le disque, en utilisant éventuellement ddrescue pour récupérer les données si nécessaire.
Gardez un œil très attentif sur le lecteur. La réallocation sectorielle est un très bon canari dans la mine de charbon, vous donnant potentiellement un avertissement précoce d'un disque défaillant. En prenant des mesures précoces, vous pouvez éviter un glissement de terrain catastrophique et très douloureux plus tard. Je ne dis pas que quelques réaffectations sectorielles sont une indication que vous devriez jeter le disque. Tous les disques modernes doivent faire une réallocation. Cependant, si le disque n'est pas très ancien (<1 an) ou si vous recevez de nouvelles réallocations fréquentes (> 1/mois), je vous recommande de le remplacer dès que possible.
Je n'ai pas de preuves empiriques pour le prouver, mais mon expérience suggère que les problèmes de disque peuvent être réduits en lisant le disque entier de temps en temps, soit par un dd du disque brut ou en lisant chaque fichier en utilisant find . Presque tous les problèmes de disque que j'ai rencontrés au cours des dernières années sont apparus d'abord dans des fichiers rarement utilisés ou sur des machines peu utilisées. Cela a également un sens sur le plan heuristique, dans la mesure où si un secteur est relu fréquemment, le lecteur a une chance de le réaffecter lorsqu'il détecte pour la première fois un problème mineur avec ce secteur plutôt que d'attendre que le secteur soit complètement illisible. Le lecteur est incapable de faire quoi que ce soit avec un secteur à moins que l'hôte n'y accède d'une manière ou d'une autre, soit en le lisant ou en l'écrivant, soit en effectuant l'un des tests SMART.
J'aimerais expérimenter l'idée d'un travail cron nocturne ou hebdomadaire qui lit l'intégralité du disque. Actuellement, j'utilise un "RAID du pauvre" dans lequel j'ai un deuxième disque dur dans la machine et je sauvegarde le disque principal dessus chaque nuit. À certains égards, c'est en fait mieux que la mise en miroir RAID, car si je gaffe et supprime un fichier par erreur, je peux obtenir la version d'hier immédiatement à partir du disque de sauvegarde. D'un autre côté, je pense qu'un contrôleur RAID matériel fait beaucoup de bon travail en arrière-plan pour surveiller, signaler et résoudre les problèmes de disque au fur et à mesure qu'ils surviennent. Mon script de sauvegarde actuel utilise rsync pour éviter de copier des données qui n'ont pas changé, mais compte tenu de la nécessité de relire tous les secteurs, il serait peut-être préférable de tout copier, ou d'avoir un script séparé qui lit l'intégralité du disque brut chaque semaine.