Fsck : corriger les erreurs d'un DD

Salut à tous,

Au démarrage de ma debian/sid, je vois apparaître des erreurs suite à une vérification de mon disque dur, en particulier sur la partition /dev/sda6 (partition /home).

Le programme de vérification des disques fsck se lancent mais ne parvient pas à résoudre les erreurs et sort un code failed(4). Il m’est donc proposer de lancer un fsck manuellement (dixit les infos en tty).

Je rentre mon mdp root et lance un fsck.etx3 /dev/sda6.

Il commande la première passe, affiche les erreurs mais ne me propose pas de corriger, seulement un :
ignore(y) et par la suite force rewrite(y) mais à la fin, rien n’est corrigé.

Que puis je faire de plus?? Sachant que j’ai déjà lancé la commande fsck avec d’autres arguments comme -y

Je remarque néanmoins que cela ne m’empêche pas de lancer ma session graphique et de travailler (créer, supprimer, modifier) dans le répertoire /home…

Merci!!

D’abord, bien distinguer le disque et le système de fichiers. Les erreurs ne sont pas les mêmes, à vérifier dans les logs du noyau.
Vérifier le disque avec smartctl et la partition avec badblocks. fsck ne peut corriger que des incohérences du système de fichiers, pas des erreurs d’accès disque.

Concernant smartctl (test “long”)

[code]smartctl 5.40 2010-07-12 r3124 [i686-pc-linux-gnu] (local build)
Copyright © 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error

1 Extended offline Completed: read failure 10% 19443 215213726

2 Extended offline Completed: read failure 10% 19383 213380099

3 Short offline Completed: read failure 10% 19382 213380099

4 Short offline Completed: read failure 10% 19382 213380099

[/code]

Et badblocks, que j’ai lancé sans arguments, badblocks /dev/sda6, m’affiche des “numéros” (que j’interprète comme des blocs défectueux??) allant de 2703552 à 7198646

J’ai également le rapport de logcheck :

[code]Date: Wed, 26 Jan 2011 08:02:09 +0100
From: logcheck system account logcheck@localhost
To: logcheck@localhost
Subject: localhost.localdomain 2011-01-26 08:02 System Events

This email is sent by logcheck. If you no longer wish to receive
such mail, you can either deinstall the logcheck package or modify
its configuration file (/etc/logcheck/logcheck.conf).

System Events
=-=-=-=-=-=-=
Jan 26 07:29:37 localhost smartd[1424]: Device: /dev/sda [SAT], FAILED SMART self-check. BACK UP DATA NOW!
Jan 26 07:29:37 localhost smartd[1424]: Device: /dev/sda [SAT], 1128 Currently unreadable (pending) sectors
Jan 26 07:29:37 localhost smartd[1424]: Device: /dev/sda [SAT], 1053 Offline uncorrectable sectors
Jan 26 07:29:37 localhost smartd[1424]: Device: /dev/sda [SAT], Failed SMART usage Attribute: 1 Raw_Read_Error_Rate.
Jan 26 07:59:36 localhost smartd[1424]: Device: /dev/sda [SAT], FAILED SMART self-check. BACK UP DATA NOW!
Jan 26 07:59:36 localhost smartd[1424]: Device: /dev/sda [SAT], 1128 Currently unreadable (pending) sectors
Jan 26 07:59:36 localhost smartd[1424]: Device: /dev/sda [SAT], 1053 Offline uncorrectable sectors
Jan 26 07:59:36 localhost smartd[1424]: Device: /dev/sda [SAT], Failed SMART usage Attribute: 1 Raw_Read_Error_Rate.[/code]

C’est donc un problème de disque et non de système de fichiers. Apparemment il y a un millier de secteurs détectés comme illisibles. Dans cette situation, il aurait été préférable de ne rien modifier ; essayer de corriger des erreurs d’origine matérielle avec fsck peut faire perdre encore plus de données. Par exemple, dans le cas où un secteur illisible contenait des inodes (définitions de fichiers et répertoires), alors les blocs alloués à ces fichiers se retrouvent “orphelins” et fsck pourrait décider de les libérer, ce qui rend leur contenu vulnérable à l’écrasement alors qu’un outil de récupération comme photorec aurait pu le retrouver.

L’option la plus sûre est de sauvegarder les données et remplacer le disque. Ensuite, tu peux éventuellement tenter de faire “réparer” ou réallouer les secteurs illisibles si tu as le temps avec badblocks en mode écriture (-w) (très long). Cela ne fera pas revenir les données illisibles, mais les secteurs réparés ou réalloués seront à nouveau utilisables. S’il reste des secteurs défectueux après plusieurs passes et si leur nombre n’augmente pas, alors il sera possible de recréer les systèmes de fichier en exécutant mkfs avec l’option -c pour détecter les secteurs illisibles et les mettre en quarantaine au niveau du système de fichiers, afin qu’ils ne soient pas utilisés. Mais le disque devra être surveillé et ne pas servir à une utilisation critique.

Une autre option consiste à exécuter fsck avec l’option -c (voire -cc) sur chaque partition pour détecter les secteurs illisibles et les mettre en quarantaine au niveau du système de fichiers, afin qu’ils ne soient pas utilisés. Mais il peut y avoir de la casse.

Mais d’autre part rien ne garantit que seule cette partition est affectée. Par défaut fsck ne vérifie que la structure d’un système de fichiers, pas ses données. Donc les blocs contenant les données des fichiers ne sont pas vérifiés à moins d’exécuter fsck avec l’option -c.

Merci pour ton analyse dans l’interprétation de ces résultats Pascal!

Mon home ne contient pas de données critiques mais juste des fichiers de configurations.
Les données importantes étant transférées directement sur un DD externe.

Je vais donc sauvegarder rapidement le disque entier.
Je pense le faire avec rsync mais, si je dois changer de DD, est ce que celui-ci peut me permettre de réinstaller l’intégralité de mon système (fichiers de conf, paquets installés) sur un nouveau DD??

Est il possible de continuer à utiliser ce disque dur tout de même???

Merci d’avance.

Difficile à dire. Le smart est tout de même pessimiste.
Une indication (qui vaut ce qu’elle vaut tout de même) est la sortie 5 de la commande smartctl -a :
5 Reallocated_Sector_Ct
qui montre le nombre de secteurs réalloués. Si le chiffre est important (on dit plus de 8 ) et surtout s’il a tendance à augmenter, le disque est bon pour la poubelle.

Difficile à dire. Cela dépend de l’état des systèmes de fichiers. Il y a peut-être d’autre fichiers sur d’autres partitions affectés par des secteurs défectueux qui n’ont pas encore été détectés, et qui ne se révèleront que lors de la sauvegarde.

En l’état, j’hésiterais.
Après remplacement et remise en état, éventuellement. Comme l’a écrit cepcasa, difficile de dire ce que ça va donner. J’ai eu des disques farcis de secteurs défectueux que j’ai réussi à faire réparer ou réallouer et qui fonctionnent sans souci particulier depuis. Mais ce n’est pas toujours le cas. La remise en état d’un disque dur est un art subtil (je ne parle pas de la méthode qui est au contraire plutôt brutale).

Le nombre de secteurs réalloués rapporté par smartcl -A est un élément capital. Mais la valeur brute en tant que telle n’est pas si importante. Ce qui compte, c’est la proportion de secteurs de réserve encore disponibles (en comparant la valeur normalisée et le seuil), et l’évolution de la valeur brute. Si elle augmente vite, c’est mauvais signe.

Un autre attribut capital est le nombre de secteurs “pending”. Un secteur pending est un secteur illisible en attente de réallocation dans un secteur de réserve disponible, qui devrait se produire lors d’une prochaine opération d’écriture (ou d’une lecture réussie) de ce secteur. Tant qu’on ne fait que le lire et que la lecture échoue, il reste pending et ne peut être réalloué. Si un secteur défaillant est réalloué sans passer par pending donc avant de devenir complètement illisible, alors cela signifie que le contrôleur intégré a bien fait son travail. La remise en état consiste à :

  1. Détecter les secteurs défectueux (-> pending) avec une lecture.
  2. Faire réallouer les secteurs pending (-> reallocated) avec une écriture.
  3. Recommencer et vérifier qu’il n’y a plus d’erreurs.

C’est ce que fait badblocks -w. Une passe peut prendre beaucoup de temps, et il faut souvent plusieurs passes pour corriger toutes les erreurs. J’utilise aussi alternativement des combinaisons de dd en lecture et en écriture car c’est plus rapide que badblocks.

Bon, voici le résultat de smartctl -A :

[code]smartctl 5.40 2010-07-12 r3124 [i686-pc-linux-gnu] (local build)
Copyright © 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000b 200 001 051 Pre-fail Always In_the_past 0
3 Spin_Up_Time 0x0007 173 165 021 Pre-fail Always - 3866
4 Start_Stop_Count 0x0032 097 097 040 Old_age Always - 3548
5 Reallocated_Sector_Ct 0x0033 198 198 140 Pre-fail Always - 29
7 Seek_Error_Rate 0x000b 200 200 051 Pre-fail Always - 0
9 Power_On_Hours 0x0032 074 074 000 Old_age Always - 19468
10 Spin_Retry_Count 0x0013 100 100 051 Pre-fail Always - 0
11 Calibration_Retry_Count 0x0013 100 100 051 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 097 097 000 Old_age Always - 3525
194 Temperature_Celsius 0x0022 113 091 000 Old_age Always - 37
196 Reallocated_Event_Count 0x0032 194 194 000 Old_age Always - 6
197 Current_Pending_Sector 0x0012 157 157 000 Old_age Always - 1128
198 Offline_Uncorrectable 0x0012 160 160 000 Old_age Always - 1053
199 UDMA_CRC_Error_Count 0x000a 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x0009 165 165 051 Pre-fail Offline - 1134
[/code]

La ligne 5 m’inquiète si je me base sur vos analyses…

Je vais lancer une tâche cron pour surveiller cette ligne et voir la progression, si il y a…

Puis je tout de même tenter une réparations avec badblocks -w??

Moi c’est plutôt la ligne 1 qui m’inquiète. La valeur normalisée de l’attribut est tombée à 1, très en dessous du seuil.

badblocks -w est une opération destructive, tu peux tenter si les données ont été sauvegardées ou transférées sur un nouveau disque.

badblocks peut endommager mon système de manière à ne plus pouvoir booter sur le disque dur??

Je vais la refaire en plus clair : badblocks -w écrase le contenu du volume (disque, partition, fichier…) auquel on l’applique.

oui.
Beaucoup de points inquiétants.
Et grosse valeur en 197 et 198 entre autre.

À ce niveau il sera difficile de corriger.

Un exemple de réallocation avec tout de même moins de secteurs touchés :
smartmontools.sourceforge.net/badblockhowto.html

Merci pour vos informations très interessantes!!

Je clos ce fil puisque je sais ce qu’il me reste à faire…