Comment identifier et réparer les fichiers avec des blocs de disque corrompus / inaccessibles

9

J'ai un Macbook Pro fin 2011, exécutant Mavericks 10.9.2. Son seul disque dur est un disque de 750 Go, formaté avec Bootcamp. Il fonctionne toujours assez bien, mais en exécutant une passe de défragmentation dessus, j'ai identifié qu'il y a un tas de fichiers qui refusent d'être déplacés par le défragmenteur (iDefrag).

iDefrag signale un code d'erreur POSIX de 5 lors de l'accès aux fichiers. Choisir un au hasard et essayer de copier le fichier vers un autre emplacement dans le shell signale également une erreur, ce qui me fait penser que le problème est réel et avec le disque / FS. La sortie de cp est:

cp: unity_nophysx.nexe: Input/output error

Le code d'erreur 5 est «accès refusé» pour autant que je sache, mais le processus de défragmentation s'exécute en tant qu'administrateur et l'exécution de cp en utilisant sudo sur le fichier suspect ne fait aucune différence.

Utilitaire de disque, fsck et Apple Hardware Test affirment tous que le disque est bien. Aucune erreur SMART n'a été signalée, et bien qu'il y ait eu des erreurs d'autorisations, elles n'étaient pas avec les fichiers dont se plaignait iDefrag, et l'Utilitaire de disque prétend les avoir corrigées sans se plaindre.

Il y a peut-être une centaine de fichiers corrompus ou plus, mais toujours une très petite fraction du lecteur. Pour autant que je sache, aucun fichier système ou donnée cruciale n'est affecté. Bien qu'il serait bien de récupérer les données, cela ne me dérange pas de réinstaller ou d'aller aux sauvegardes. À ce stade, je ne sais pas si c'est vraiment le lecteur qui meurt, juste quelques secteurs défectueux en raison du déplacement du lecteur pendant l'écriture, ou une autre corruption mineure qui peut être contournée. J'imagine le pire des cas, et que je devrai probablement obtenir un disque dur légèrement plus grand et cloner le disque existant pour éviter d'avoir à reconstruire le système.

Ma question est vraiment de savoir comment procéder pour marquer ces fichiers cassés comme correctement cassés et les réparer ou les purger , afin qu'un clone du disque réussisse et ne se bloque pas sur les fichiers / blocs auxquels il ne peut pas accéder. L'Utilitaire de disque ne voit pas le problème, et je ne connais pas de ligne de commande ou d'outils tiers qui feront le travail. Je ne veux pas effacer le disque entier et recommencer à zéro, car le lecteur semble par ailleurs sain, donc je recherche des outils de réparation / diagnostic.

— MrCranky
source

Je vous conseille de lire cette discussion similaire assez détaillée sur SuperUser: superuser.com/q/148227 .

— dan

J'ai testé, malheureusement sur un disque sain :), volitans-software.com/smart_utility.php . Cela ressemble à un outil assez simple et sérieux. Vous pouvez l'essayer et vérifier notamment le compteur "secteurs réaffectés".

— dan

8

Si vous êtes confronté à un système de fichiers sain au niveau de sa structure et que vous souhaitez rechercher des fichiers contenant des blocs défectueux sur le disque, voici comment procéder:

Faites une sauvegarde complète de votre disque avec Time Machineou Carbon Copy Cloner

Vérifiez cette sauvegarde.
Exécutez la commande lourde et risquée suivante (si vous avez des blocs défectueux en dehors de votre structure de système de fichiers) (assurez-vous que le {} est cité pour que les noms de fichiers contenant des espaces fonctionnent):
```
find / -type f -print -exec dd if="{}" of=/dev/null bs=1m \;
```

Cette findcommande lourde affichera pour tout fichier brut son nom (donc pas la lecture, mais juste son entrée de répertoire) et continuera ensuite à faire une lecture complète et rapide de tous ses blocs de données.

Sur hiting le premier fichier contenant des blocs défectueux, cela findprovoquera le noyau de se connecter read errorsur /var/log/system.log, et il soit ralentir ou mettre votre système à un arrêt total. Cela dépendra principalement de la capacité du disque dur à déplacer les blocs défectueux trouvés sur son pool interne dédié à cette tâche de correction habituelle. Ce fichier contenant des blocs défectueux sera le nom de famille imprimé par find.

Notez ce nom de fichier sur un morceau de papier! Disons que ce nom de fichier est:

/.DocumentRevisions-V100/.cs/ChunkStorage/0/0/0/9

À ce stade, vous pouvez avoir la possibilité de tuer findrapidement en appuyant sur ctrl+ C. Si le tuer correctement échoue, plantez simplement votre Mac.

Au redémarrage de votre Mac, vérifiez directement le fichier contenant les blocs défectueux:

dd if='/.DocumentRevisions-V100/.cs/ChunkStorage/0/0/0/9' of=/dev/null bs=1m

Si la commande se termine correctement, l'erreur était suffisamment légère pour que votre disque puisse lire ce fichier et réallouer les blocs défectueux.

Si la commande ne se termine pas, vous ne pourrez pas la tuer normalement, vos données seront totalement perdues et vous devrez à nouveau planter votre Mac.

Dans ce dernier cas, vous devez envisager de remplacer votre disque et de travailler à partir de vos dernières sauvegardes. Certains autres fichiers peuvent également contenir des blocs défectueux et peuvent ne pas être détectés depuis longtemps tant que vous ne les avez pas lus.

Le noyau ne déclenchera pas d'erreur de lecture sur un bloc que vous n'avez jamais lu.

— dan
source

Aha, c'est absolument le genre de truc que j'espérais. La première passe avec le script find / dd touche tous les fichiers / blocs sur le disque, et bien sûr, je trouve un tas de fichiers qui donnent "Erreur d'entrée / sortie", et je peux simplement sortir le journal de la commande dans un fichier et puis grep pour savoir quels fichiers sont duff. Il semble que la commande dd ne soit pas elle-même suffisante pour déclencher une sorte de correction automatique (je ne savais même pas qu'OS X l'avait fait), mais au moins elle me donne un moyen fiable d'identifier les fichiers.

— MrCranky

Du côté positif, lorsque le système d'exploitation essaie de lire à partir des fichiers avec ces mauvais blocs, il ne plante pas ou ne raccroche pas horriblement. Je vois une May 10 20:42:15 ICE kernel[0]: disk0s2: I/O error.fenêtre contextuelle dans les journaux, mais aucun indice quant au fichier qui l'a déclenché. Mais alors, la commande s'exécute très heureusement.

— MrCranky

Votre noyau ne se bloque pas avec le BBFH car votre disque a encore suffisamment de blocs disponibles dans son pool pour corriger les mauvais blocs. ddne règle rien, cette commande a pour but de copier les données et de les convertir le plus rapidement possible. Le disque est toujours capable de réparer les erreurs légères. Restez vigilant, le prix d'un disque n'a rien à voir avec votre travail.

— dan

Mmm, oui, je supposais que: dd étant juste un outil stupide pour extraire toutes les données d'un fichier et les mettre ailleurs (dans notre cas, dans l'air). Ce qui compte vraiment, c'est que chaque bloc associé au fichier soit lu. Ce que je ne comprends pas, c'est ce que vous attendez d'OS X dans ce cas. De toute évidence, le noyau ne peut pas lire ces mauvais blocs, mais pensez-vous que le disque lui-même peut et peut les réparer? S'il ne peut pas extraire les données du mauvais bloc d'origine, comment va-t-il les déplacer ailleurs?

— MrCranky

Excellente question. Le disque fera automatiquement des tentatives de lecture des blocs. Chaque fois que la position de la tête est mécaniquement dans une position différente. Si l'une de ces tentatives réussit, les données sont copiées sur l'un des blocs disponibles pour réparer les blocs défectueux. Le mauvais bloc est signalé comme mauvais et ne sera plus jamais utilisé. D'un autre côté, si toutes les tentatives échouent, les données ne sont pas enregistrées et après un très long moment, le disque marquera le bloc comme étant mauvais et allouera un nouveau vide au disque visible. Le noyau signalera une erreur de disque irrécupérable.

— dan

4

Redémarrez en mode mono-utilisateur en maintenant le Command+ Spendant le démarrage. Lorsque vous voyez une invite (devrait ressembler root #ou quelque chose de similaire), tapez fsck -fet appuyez sur Return. Il s'agit de l'outil de vérification de cohérence du système de fichiers intégré à Mac et vous permet de rechercher et de réparer les erreurs avec le système de fichiers de démarrage. Exécutez cette commande jusqu'à ce que vous ne voyiez pas **The volume [volume name] was modified.**ou que l'outil échoue trois fois de suite.

Si l'outil échoue, cela pourrait indiquer un problème plus important (mais je ne pourrais pas vous dire quoi sans voir la sortie de l'outil). Dans tous les cas, assurez-vous d'avoir sauvegardé tout ce que vous pouvez avant d'exécuter un outil de disque. Lorsque vous avez terminé, tapez rebootl'invite et appuyez sur Entrée pour (vous l'avez deviné!) Redémarrer votre ordinateur.

Pour plus d'informations, vous pouvez trouver les pages de manuel fsck ici .

— Mat
source

Intéressant, mais il ressemble beaucoup à fsck, même avec -f et en mode mono-utilisateur, fait exactement ce que Disk Utility a fait. Comme l'Utilitaire de disque, il ne trouve rien et pense que le disque est très bien. Je suppose qu'il analyse les enregistrements du système de fichiers, mais je pense que mon problème est au niveau du bloc - c'est-à-dire que le système de fichiers est bien structuré, mais les données réelles dans les fichiers ne sont pas accessibles en ce qui concerne la lecture / les copier / les défragmenter.

— MrCranky

1

→ MrCranky: c'est vrai! fsck& Disk Utilityvérifient l'intégrité de la structure du système de fichiers. Ils lisent les blocs de disques alloués à la structure du système de fichiers. Ils ne sont pas faits pour vérifier l'intégrité des blocs de données. Par conséquent, ils peuvent fonctionner sur un disque avec des blocs défaillants sans augmenter aucune erreur de lecture. Si vous souhaitez vérifier votre disque, même les blocs qui peuvent être défectueux mais qui sont en fait inutilisés, utilisez simplement un outil de base au fur dd if=/dev/disk0 of=/dev/null ibs=1ket à mesure de l'exécution d'une autre fenêtre de shell tail -f /var/log/system.log. C'est gratuit, extrême et ne vous cachera aucune erreur.

— dan

2

Je recommande fortement DiskWarrior pour reconstruire les catalogues de disques et pour rechercher les fichiers potentiellement endommagés .

Lors de la reconstruction du catalogue, il peut également vous faire savoir s'il rencontre un retard en raison d'un dysfonctionnement du disque.

— Adam
source

Je ne suis pas opposé à l'achat d'un outil pour vous aider, mais sans essai et sans garantie qu'il est même conçu pour trouver le type d'erreurs que je rencontre, j'aurais besoin de beaucoup plus de recommandations pour sauvegarder le vôtre avant d'être prêt à déposer 100 $ sur un outil.

— MrCranky

-1 Pas seulement une réponse, mais un mélange de commentaires et de réponses.

— Max Ried

2

En travaillant sur la réponse de Buscar, vous pouvez le faire automatiquement en utilisant un truc de ligne de commande assez lourd.

sudo find / -type f -print0  | xargs -0 -I{} dd if='{}' of=/dev/null bs=1m 2>&1 | grep 'error' >>badfiles.txt  &

sudo: mode administrateur
find -print0: chemin absolu
xargs -0 -I {}: remplacer {} dans la commande suivante
dd 2> & 1: rediriger l'erreur std vers stdout
pipe stdout à grep à la recherche d'une erreur de chaîne
Ajoutez les résultats à un fichier de liste. ( Remarque : Cela devrait être sur un support externe si vous pensez que votre lecteur interne est incertain)

— awiebe
source

1

Comme vous le dites, il n'est même pas clair que ces fichiers sont endommagés, du moins votre Mac ne le pense pas.

Chaque système d'exploitation crée des fichiers inamovibles qui sont nécessaires à ses opérations (points de restauration, fichiers actuellement actifs, etc.). Certaines défragmentation les montreront, d'autres non.

Le fait que vous ne puissiez pas y accéder ou les déplacer ne signifie pas qu'ils sont endommagés.

Normalement, les Mac sont très bons pour prendre soin d'eux-mêmes.

L'utilisation de la maintenance Apple se fait en: ouvrant le terminal et en tapant:

sudo periodic daily weekly monthly

suivi de Retour, entrez votre mot de passe Administrateur et OS X s'occupera des choses pour vous.

Regardez dans la console pour les rapports sur ceux-ci si vous êtes intéressé.

Dans la console, recherchez (recherchez) les erreurs d'E / S qui indiqueraient que votre disque commence à avoir des problèmes, pour complimenter l'utilitaire de disque et les constatations de fsck.

À l'occasion, j'utilise un outil gratuit appelé OnyX pour des tâches de maintenance supplémentaires. Il est fait par des français et comme ils mangent c'est tout simplement génial :)

_{OnyX est un utilitaire multifonction pour OS X qui vous permet de vérifier le disque de démarrage et la structure de ses fichiers système, d'exécuter diverses tâches de maintenance du système, de configurer certains paramètres cachés du Finder, Dock, QuickTime, Safari, Mail, iTunes , la fenêtre de connexion, Spotlight et de nombreuses applications d'Apple, pour supprimer les caches, supprimer un certain nombre de fichiers et de dossiers qui peuvent devenir encombrants, etc.}

Cela dit, je ne remets pas en question votre décision d'utiliser le défragmenteur (iDefrag) car je ne le connais pas, mais plutôt de proposer des solutions alternatives.

— Ruskes
source

L'utilisation du défragmenteur n'est pas le problème, je suis parfaitement conscient de ce que OS X fait et ne fait pas à cet égard. Les fichiers n'étaient définitivement pas utilisés, il s'agissait de fichiers de données pour une application qui n'était pas active, et en effet l'application ne peut plus être déplacée.

— MrCranky

Sur Onyx - il fait encore un peu plus que l'Utilitaire de disque - vérifiant l'état SMART du disque puis exécutant le diagnostic de style fsck (qui, comme nous l'avons établi, pense qu'il n'y a rien de mal)

— MrCranky

Juste pour être clair, pour quiconque lisant cette réponse, les fichiers ont certainement été endommagés, et le Mac le savait, car je n'avais pas le droit de les lire (copiez-les, peu importe). Ce n'était pas parce qu'il s'agissait de fichiers système, ou en cours d'utilisation à l'époque, c'était vrai même pour les fichiers de données utilisateur. La maintenance périodique n'a pas aidé à résoudre le problème, encore une fois car, comme fsckil semble ne se soucier que des problèmes de système de fichiers, pas bloquer les problèmes d'accessibilité. La console n'a montré d'erreurs que lorsque j'ai essayé manuellement de copier / lire les données de l'un de ces fichiers cassés, cela ne m'a pas aidé à les trouver.

— MrCranky

0

Aussi déraisonnable que cela puisse paraître, avant de faire quoi que ce soit, vous devez dupliquer toutes vos données sur un bon disque connu. Si le démarrage à partir du programme d'installation et la copie des données échouent, il existe un utilitaire de ligne de commande appelé «dd» qui peut effectuer une duplication de bas niveau et de manière beaucoup plus intransigeante.

 man dd

pour plus d'informations sur dd, y compris l'utilisation et la syntaxe appropriée.

Un autre vote pour le post de Matt, démarrez le mode mono-utilisateur et exécutez

 fsck -fy

encore et encore jusqu'à ce que fsck cesse de signaler des erreurs.

Vote pour la publication d'Adam, DiskWarrior est une application simple à utiliser mais très puissante qui signalera les défaillances du disque dur, vérifiera les fichiers individuels pour les erreurs et les réparera si possible, et reconstruira et optimisera les structures de répertoires.

Une autre solution possible qui peut sembler déraisonnable mais qui est souvent une dernière tentative de récupérer des données avec beaucoup de preuves annacdotiques de succès est de retirer le lecteur, de le protéger de l'humidité à l'aide de quelques couches de sacs de congélation et de le placer dans votre congélateur pour 30-45 minutes. Ensuite, pendant que le lecteur est froid, montez le lecteur sur une station d'accueil USB externe et utilisez un autre système temporaire pour tenter à nouveau de copier les données corrompues sur un autre lecteur. En règle générale, cette option est utilisée en cas de problème matériel et de panne du lecteur. Si vous pouvez dupliquer l'intégralité du disque avec vos données intactes, c'est l'idéal, car souvent une répartition et un reformatage donneront au disque un nouveau souffle.

— chillin
source

Comme je l'ai dit, fsck ne signale aucune erreur. Le disque n'est pas encore capricieux ou ne signale pas d'erreurs aléatoires, et la liste des fichiers qui sont corrompus ne semble pas s'allonger, donc je ne pense pas que je sois encore proche de l'étape de `` geler pour une dernière traction d'urgence ''. Je suis également déjà très bien sauvegardé au niveau des fichiers / dossiers et je ne crains pas de perdre des données, comme je l'ai dit dans la question. Bon d'entendre un autre vote pour DiskWarrior cependant.

— MrCranky

@MrCranky: Je pense que vous faites référence à quelque chose posté avant la mise à jour de votre question; Je renforçais l'idée de fsck pour tous ceux qui trouvent cette page à la recherche d'une solution à des symptômes similaires. En ce qui concerne tout ce que j'ai publié sur l'échec du disque dur, cela ne fait jamais de mal d'être complet, encore une fois, pour les autres et pas nécessairement pour vous personnellement. J'ai vu ma juste part de pannes de disque dur. Il n'y a souvent aucune indication d'échec, même avec la technologie SMART, jusqu'à ce que vous ne puissiez plus accéder aux données par aucun moyen. Si vous vous souciez des données, je vous recommande fortement d'obtenir un nouveau lecteur et de sauvegarder vos données.

— chillin

Je ne suis certainement pas en désaccord avec la recommandation de sauvegarde, mais l'esprit du format Q&A est de répondre à la question qui est posée, pas à une question générique "comment réparer un disque cassé" (dont il y en a beaucoup). Bien avant de le modifier pour l'ajouter fsckà la liste des "choses qui pensent que le disque est bien", j'avais répondu à la réponse en mentionnant fsckson utilité. fscket Disk Utility remplissent à peu près la même fonction, c'est-à-dire qu'ils opèrent sur les structures du système de fichiers, pas au niveau du bloc. J'ai essayé d'être assez précis sur le fait qu'il s'agit d'un problème de bloc, pas d'un problème de système de fichiers.

— MrCranky

0

Pour un seul fichier qui ne peut pas être lu dans son intégralité en raison d'une erreur de lecture de disque, vous pouvez utiliser l' ddutilitaire pour dupliquer le fichier sur un volume externe, en substituant des octets NUL aux blocs qui ne peuvent pas être lus. Il est fortement recommandé de dupliquer sur un volume différent (par exemple "Disque USB" dans l'exemple ci-dessous).

Exemple:

dd if=/path/to/damaged/file of=/Volumes/USB\ Disk/file bs=512 conv=noerror,sync

En utilisant des blocs de 512 octets, le nombre maximal de blocs lisibles sera récupéré.

La récupération peut prendre beaucoup de temps, car le noyau se bloquera pendant un certain temps à chaque échec de lecture.

— bleater
source