Forum Linux.général Disque dur HS ?

Posté par  . Licence CC By‑SA.
Étiquettes :
3
3
sept.
2020

Bonjour,

mon serveur "plante" régulièrement. Je ne peux plus me connecter en SSH (il demande le mot de passe puis ferme la connexion immédiatement). Après reboot il re-fonctionne parfois.

Ce matin j'ai eu plus d'infos car semble-t-il le problème s'est produit alors que j'étais déjà connecté en SSH.

J'ai vu ça avec la commande dmesg :

[ 116.143835] Aborting journal on device sda1-8.
[ 116.168822] EXT4-fs (sda1): Remounting filesystem read-only
[ 116.177120] EXT4-fs error (device sda1): ext4_journal_check_start:56: Detected aborted journal

Mon système de fichier est effectivement en read-only (ce qui explique sans doute l'impossibilité d'ouvrir une nouvelle connexion SSH)

J'ai ensuite utilisé ces commandes :

smartctl -t short /dev/sda
(attente de 2 minutes)
smartctl -l selftest /dev/sda

J'ai la sortie suivante :

=== 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 Short offline Completed: read failure 90% 26649 2038474392
# 2 Short offline Completed: read failure 90% 26649 2038474392

Est ce que ça veut dire que mon disque dur est foutu ? Ou y a-t-il des choses à tenter pour réparer le système de fichier, isoler les secteurs défectueux ou que sais-je ?

Merci pour votre aide.

  • # Réflexes

    Posté par  . Évalué à 3.

    Salut,

    Moi, dans ta situation, je réfléchirais que 5 secondes :

    • backup si c'est pas fait,
    • changement de disque.

    Matricule 23415

    • [^] # Re: Réflexes

      Posté par  . Évalué à 3.

      Oui, pour les backup c'est fait régulièrement depuis bien avant la panne, pas de soucis :-) Ouf.

  • # Foutu ? Pas nécessairement.

    Posté par  (site web personnel) . Évalué à 6.

    Pour répondre à la question — qu'il fallait effectivement postposer jusqu'à sauvegarde de toutes les données importantes : non ça ne veut pas forcément dire que le disque dur est fichu. Simplement des données qu'on a tenté de lire le sont. En récrivant sur les positions défectueuses de nouvelles données, le disque devrait aller puiser dans ses réserves pour réallouer des emplacements fonctionnels si je ne m'abuse. J'ai déjà eu des cas de telles erreurs ou les disques durs ont repris de bons et loyaux services pour de longues années après de telles alertes. Toutefois il arrive aussi que les premières erreurs soient le vaguemestre annonçant l'invasion massive, et la déroute du disque. Prudence donc.

    « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

    • [^] # Re: Foutu ? Pas nécessairement.

      Posté par  . Évalué à 2.

      OK, merci pour l'info. Je vais voir si j'arrive à faire quelque chose avec badblocks par exemple, sinon je reformaterais tout pour voir. Si j'ai à nouveau des problèmes je changerais le disque, mais ça vaut peut-être le coup de lui donner une deuxième chance effectivement.

    • [^] # Re: Foutu ? Pas nécessairement.

      Posté par  . Évalué à 3.

      En récrivant sur les positions défectueuses de nouvelles données, le disque devrait aller puiser dans ses réserves pour réallouer des emplacements fonctionnels si je ne m'abuse.

      Oui, normalement ça se fait automatiquement avec une écriture sur le bloc défaillant (une passe de badblocks ou une écriture ciblée avec dd si comme ici on connait déjà le secteur incriminé). Ça se vérifie avec l'attribut 5 de SMART (Reallocated sector count) qui doit s'incrémenter. On peut aussi vérifier que ça a été fait automatiquement avec l'attribut 197 de SMART (Pending sector count) qui doit rester à zéro, sinon il faut le faire manuellement avec smartctl.

      J'ai déjà eu des cas de telles erreurs ou les disques durs ont repris de bons et loyaux services pour de longues années après de telles alertes.

      Pareil, ça peut arriver pendant la période de rodage. C'est quand le disque prend de l'âge ou qu'il y a beaucoup de secteurs morts que ça devient inquiétant.

  • # badblocks

    Posté par  (site web personnel) . Évalué à 2.

    Le premier réflexe, c'est faire une sauvegarde ET la vérifier.
    Ensuite, tu peux isoler les blocs défectueux, soit avec la commande badblocks, soit avec "e2fsck -c", ce qui devrait permettre de redemarrer pour un certain temps.
    Après, il va falloir surveiller pour voir si le nombre de secteurs défectueux reste à peu près constant ou explose (ce qui est le signe d'un disque qui lache). Tu peux le faire en comparant la liste des secteurs renvoyés par badblocks.

    • [^] # Re: badblocks

      Posté par  . Évalué à 1.

      OK, merci je vais tester e2fsck -c

      Juste une question : si cette commande marque les secteurs à ne pas utiliser, mais que par la suite je formate le disque, il va à nouveau essayer d'utiliser ces secteurs défectueux ?

  • # Debian kernel 4.19.0-10 ?

    Posté par  . Évalué à 5.

    Difficile de dire si les pépins avec lesquels je me bats depuis plus d'un an sont liés, mais notez que j'ai découvert méchamment que le dernier kernel de la Debian Stable, le 4.19.0-10 crashe sur certaines configs. Ça n'est pas le seul, ça grimpe jusqu'au 5.7 il me semble.
    Ça semble partir d'un paquet réseau (testé avec du sky2 et du RTL8169), et ça remonte jusqu'à __cgroup_bpf_run_filter_skb. Machine freezée, reset. J'ai des photos d'écran pour ceux que ça intéresse, mais c'est pas pratique à insérer ici.

    Solution : retour au 4.19.0-9.

    Ceci dit, avant ça, les pépins avec lesquels je me frittait tournaient autour du SATA aussi, avec un semblant de perte de communication avec un des disques, la récupération avec baisse des perfs : passage en UDMA-133, ou un truc du genre. Ah, j'ai retrouvé du log :

    [Thu Jul  2 22:08:21 2020] ata10.00: exception Emask 0x0 SAct 0x4000000 SErr 0x0 action 0x6 frozen
[Thu Jul  2 22:08:21 2020] ata10.00: failed command: WRITE FPDMA QUEUED
[Thu Jul  2 22:08:21 2020] ata10.00: cmd 61/80:d0:80:46:64/01:00:51:00:00/40 tag 26 ncq dma 196608 out
                                    res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[Thu Jul  2 22:08:21 2020] ata10.00: status: { DRDY }
[Thu Jul  2 22:08:21 2020] ata10: hard resetting link
[Thu Jul  2 22:08:21 2020] ata10: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[Thu Jul  2 22:08:21 2020] ata10.00: configured for UDMA/133
[Thu Jul  2 22:08:21 2020] ata10: EH complete

    J'ai tout essayé : 15 changements de câble SATA, changement de MoBo/RAM/CPU, passage sur une carte SATA additionnelle, j'ai viré tout ce que je pouvais virer, remplacé la carte vidéo plusieurs fois …

    Là, après un rinçage du BIOS et une réinstalle de l'OS (et le fameux retour au 4.19.0-9), ça semble enfin réglé.

  • # wiki smartmontools

    Posté par  . Évalué à 4.

    Est ce que ça veut dire que mon disque dur est foutu ? Ou y a-t-il des choses à tenter pour réparer le système de fichier, isoler les secteurs défectueux ou que sais-je ?

    Une page (en anglais) du wiki du projet smartmontools décrit plusieurs stratégies visant à résoudre ce type de problème.

  • # Commentaire supprimé

    Posté par  . Évalué à 1. Dernière modification le 16 novembre 2020 à 15:12.

    Ce commentaire a été supprimé par l’équipe de modération.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.