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 _kaos_ . Évalué à 3.
Salut,
Moi, dans ta situation, je réfléchirais que 5 secondes :
Matricule 23415
[^] # Re: Réflexes
Posté par neuoy . É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 ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (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 neuoy . É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 ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 6.
Un formatage (à moins qu'il soit bas niveau et n'écrive partout) ne devrait rien résoudre. À moins que ce n soit les parties réservées au système de fichier qui posent problème.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Foutu ? Pas nécessairement.
Posté par Anonyme . Évalué à 3.
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.
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 eric gerbier (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 neuoy . É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 AncalagonTotof . É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 :
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 Pilou . Évalué à 4.
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 braindumps4it . É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.