reset les notifications smartd OfflineUncorrectableSector
Bonjour, Sur une machine en raid5 mdadm, j'ai des notifications smartd avec Device: /dev/sda [SAT], 63 Offline uncorrectable sectors Device: /dev/sdc [SAT], 1 Offline uncorrectable sectors D'après ce que j'ai pu comprendre, c'est pas dramatique tant que ça n'évolue pas, mais comment faire un reset des notifications smartd (qu'il arrête de me notifier chaque jour pour cette erreur et me notifie de nouveau si ça change) ? (smartd 7.2 sur debian11) Merci -- Daniel Quand on est trop bonne pâte, on risque de finir dans le pétrin. Pierre Dac
Ah t’es sport toi :) Perso quand j’ai ça, je change le disque. Pas forcément en urgence, mais sous 3/4 semaines. Ou alors tu fais un gros pari sur la linéarité du départ en sucette du HD. Ok, t’es en RAID1, mais le changer avant t’évitera un jour un changement qui lui sera plutôt urgent. Ce n’est qu’un avis personnel. David
Le 23 janv. 2023 à 11:27, Daniel Caillibaud <ml@lairdutemps.org> a écrit :
Bonjour,
Sur une machine en raid5 mdadm, j'ai des notifications smartd avec
Device: /dev/sda [SAT], 63 Offline uncorrectable sectors Device: /dev/sdc [SAT], 1 Offline uncorrectable sectors
D'après ce que j'ai pu comprendre, c'est pas dramatique tant que ça n'évolue pas, mais comment faire un reset des notifications smartd (qu'il arrête de me notifier chaque jour pour cette erreur et me notifie de nouveau si ça change) ?
(smartd 7.2 sur debian11)
Merci
-- Daniel
Quand on est trop bonne pâte, on risque de finir dans le pétrin. Pierre Dac _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Hello,
Ah t’es sport toi :) Perso quand j’ai ça, je change le disque. Pas forcément en urgence, mais sous 3/4 semaines.
Pareil que David, if (uncorrectable sectors) then changediskasap(); SURTOUT avec du mdadm, il y a probablement d'autres secteurs en train de faire plouf et le changement fera que tu en trouvera d'autres... avec peut-être une perte de ta grappe... Sachant qu'en raid5 : 2 HD de perdu -> data perdu... Xavier
Il me semble d’ailleurs qu’il y un proverbe qui dit « un bon RAID5, c’est pas de RAID5 » :)
Le 24 janv. 2023 à 10:39, Xavier Beaudouin via FRsAG <frsag@frsag.org> a écrit :
Hello,
Ah t’es sport toi :) Perso quand j’ai ça, je change le disque. Pas forcément en urgence, mais sous 3/4 semaines.
Pareil que David, if (uncorrectable sectors) then changediskasap();
SURTOUT avec du mdadm, il y a probablement d'autres secteurs en train de faire plouf et le changement fera que tu en trouvera d'autres... avec peut-être une perte de ta grappe... Sachant qu'en raid5 : 2 HD de perdu -> data perdu...
Xavier _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Le Mon, Jan 23, 2023 at 11:27:12AM +0100, Daniel Caillibaud a écrit:
Bonjour,
Sur une machine en raid5 mdadm, j'ai des notifications smartd avec
Device: /dev/sda [SAT], 63 Offline uncorrectable sectors Device: /dev/sdc [SAT], 1 Offline uncorrectable sectors
D'après ce que j'ai pu comprendre, c'est pas dramatique tant que ça n'évolue pas, mais comment faire un reset des notifications smartd (qu'il arrête de me notifier chaque jour pour cette erreur et me notifie de nouveau si ça change) ?
(smartd 7.2 sur debian11)
Tu modifies les paramètres dans smartd.conf: DEVICESCAN -d removable -n standby -m root -M exec /usr/share/smartmontools/smartd-runner -o on -S on -s (S/../.././02|L/../../6/03) -a # -a Default: equivalent to -H -f -t -l error -l selftest -C 197 -U 198 # -C ID Report if Current Pending Sector count non-zero # -U ID Report if Offline Uncorrectable count non-zero ---> DEVICESCAN -d removable -n standby -m root -M exec /usr/share/smartmontools/smartd-runner -o on -S on -s (S/../.././02|L/../../6/03) -H -f -t -l error -l selftest -C 197 -U 198+ Le "+" (que tu peux aussi mettre sur le 197 si besoin) indique de ne mailer /que/ s'il y a une modification. Par contre, comme dit David, c'est à surveiller de près. Si ça ne bouge pas, c'est pas catastrophique, mais si tu en as plusieurs qui se rajoutent "régulièrement", il est temps de changer le disque préventivement. Arnaud.
Moais... sauf improbable faux positifs dans les erreurs rapportées, un disque qui a des trous c'est un disque en sursis. Admettons que l'autre disque claque net, tu va donc faire une reconstruction à partir d'un support moisi. Tu joues, tu perds, faut pas pleurer... Le 23/01/2023 à 12:40, Arnaud Launay a écrit :
Le Mon, Jan 23, 2023 at 11:27:12AM +0100, Daniel Caillibaud a écrit:
Bonjour,
Sur une machine en raid5 mdadm, j'ai des notifications smartd avec
Device: /dev/sda [SAT], 63 Offline uncorrectable sectors Device: /dev/sdc [SAT], 1 Offline uncorrectable sectors
D'après ce que j'ai pu comprendre, c'est pas dramatique tant que ça n'évolue pas, mais comment faire un reset des notifications smartd (qu'il arrête de me notifier chaque jour pour cette erreur et me notifie de nouveau si ça change) ?
(smartd 7.2 sur debian11) Tu modifies les paramètres dans smartd.conf:
DEVICESCAN -d removable -n standby -m root -M exec /usr/share/smartmontools/smartd-runner -o on -S on -s (S/../.././02|L/../../6/03) -a
# -a Default: equivalent to -H -f -t -l error -l selftest -C 197 -U 198 # -C ID Report if Current Pending Sector count non-zero # -U ID Report if Offline Uncorrectable count non-zero
--->
DEVICESCAN -d removable -n standby -m root -M exec /usr/share/smartmontools/smartd-runner -o on -S on -s (S/../.././02|L/../../6/03) -H -f -t -l error -l selftest -C 197 -U 198+
Le "+" (que tu peux aussi mettre sur le 197 si besoin) indique de ne mailer /que/ s'il y a une modification.
Par contre, comme dit David, c'est à surveiller de près. Si ça ne bouge pas, c'est pas catastrophique, mais si tu en as plusieurs qui se rajoutent "régulièrement", il est temps de changer le disque préventivement.
Arnaud. _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Oui. Le niveau 5 est plus confortable ... --- Bernard BELLE - C.F.G.I. ---------------------------------- Envoyé depuis mon AMSTRAD CPC 6128 ---------------------------------- Le 2023-01-23 12:59, Pierre Colombier via FRsAG a écrit :
Moais... sauf improbable faux positifs dans les erreurs rapportées, un disque qui a des trous c'est un disque en sursis.
Admettons que l'autre disque claque net, tu va donc faire une reconstruction à partir d'un support moisi.
Tu joues, tu perds, faut pas pleurer...
Le 23/01/2023 à 12:40, Arnaud Launay a écrit :
Le Mon, Jan 23, 2023 at 11:27:12AM +0100, Daniel Caillibaud a écrit:
Bonjour,
Sur une machine en raid5 mdadm, j'ai des notifications smartd avec
Device: /dev/sda [SAT], 63 Offline uncorrectable sectors Device: /dev/sdc [SAT], 1 Offline uncorrectable sectors
D'après ce que j'ai pu comprendre, c'est pas dramatique tant que ça n'évolue pas, mais comment faire un reset des notifications smartd (qu'il arrête de me notifier chaque jour pour cette erreur et me notifie de nouveau si ça change) ?
(smartd 7.2 sur debian11) Tu modifies les paramètres dans smartd.conf:
DEVICESCAN -d removable -n standby -m root -M exec /usr/share/smartmontools/smartd-runner -o on -S on -s (S/../.././02|L/../../6/03) -a
# -a Default: equivalent to -H -f -t -l error -l selftest -C 197 -U 198 # -C ID Report if Current Pending Sector count non-zero # -U ID Report if Offline Uncorrectable count non-zero
--->
DEVICESCAN -d removable -n standby -m root -M exec /usr/share/smartmontools/smartd-runner -o on -S on -s (S/../.././02|L/../../6/03) -H -f -t -l error -l selftest -C 197 -U 198+
Le "+" (que tu peux aussi mettre sur le 197 si besoin) indique de ne mailer /que/ s'il y a une modification.
Par contre, comme dit David, c'est à surveiller de près. Si ça ne bouge pas, c'est pas catastrophique, mais si tu en as plusieurs qui se rajoutent "régulièrement", il est temps de changer le disque préventivement.
Arnaud. _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Liste de diffusion du %(real_name)s http://www.frsag.org/
Le 23/01/23 à 12:40, Arnaud Launay <asl@launay.org> a écrit :
Tu modifies les paramètres dans smartd.conf:
[…] Merci pour la solution !
Par contre, comme dit David, c'est à surveiller de près. Si ça ne bouge pas, c'est pas catastrophique, mais si tu en as plusieurs qui se rajoutent "régulièrement", il est temps de changer le disque préventivement.
C'est un serveur en location, il va falloir que j'en change… (chez ovh je m'amuse plus à demander au support de changer un disque, c'était y'a longtemps mais je me rappelle encore des déboires que ça avait entraîné, je préfères changer de machine, et ici rien ne dit que le changement d'un disque va pas claquer les autres à la reconstruction). Et si ça claque avant que je migre, tant pis, je repartirai sur un autre avec le backup de la veille, y'a rien de vital dessus. -- Daniel Pour moi le plus grand supplice serait d'être seul au paradis. Goethe
je changerait le disque aussi. la procédure chez OVH a bien changé. et est sans risque. le disque est changé a froid de toute manière, tu fourni le serial du disque a changer, le cat /proc/mdstat et les sorties de smartctl, et un créneau horaire pour changer le disque, et c'est fait. avant ça, chez nous la procédure est d'update-initramfs -u et grub-install sur tous les disques (et de recopier la partition EFI s'il y en a). Le 23/01/2023 à 20:47, Daniel Caillibaud a écrit :
Le 23/01/23 à 12:40, Arnaud Launay <asl@launay.org> a écrit :
Tu modifies les paramètres dans smartd.conf: […]
Merci pour la solution !
Par contre, comme dit David, c'est à surveiller de près. Si ça ne bouge pas, c'est pas catastrophique, mais si tu en as plusieurs qui se rajoutent "régulièrement", il est temps de changer le disque préventivement. C'est un serveur en location, il va falloir que j'en change… (chez ovh je m'amuse plus à demander au support de changer un disque, c'était y'a longtemps mais je me rappelle encore des déboires que ça avait entraîné, je préfères changer de machine, et ici rien ne dit que le changement d'un disque va pas claquer les autres à la reconstruction).
Et si ça claque avant que je migre, tant pis, je repartirai sur un autre avec le backup de la veille, y'a rien de vital dessus.
Bonjour Je suis a la recherche d’un consultant / admin sys spécialisé Ceph pour une mission en vue de nous aider a optimiser 2 clusters actuellement en production. Les 2 clusters sont managés via cephadm et sont déployés sous ubuntu en containers Merci de me contacter en MP Cordialement
Le 24/01/23 à 09:06, Pierre DOLIDON <sn4ky@sn4ky.net> a écrit :
je changerait le disque aussi. la procédure chez OVH a bien changé. et est sans risque.
Mmh, changer un disque sur du raid soft, c'est jamais sans risque. Et des changements de composant où c'est pas le bon qui est changé, j'en ai vu plusieurs, même si c'était y'a qq années car après plusieurs grosses galères j'ai plus jamais demandé de changement de composant, je change de machine.
le disque est changé a froid de toute manière, tu fourni le serial du disque a changer, le cat /proc/mdstat et les sorties de smartctl, et un créneau horaire pour changer le disque, et c'est fait.
Avec du raid5 et deux disques sur trois ayant des pbs, le risque de crasher un autre disque à la reconstruction du raid est pas négligeable.
avant ça, chez nous la procédure est d'update-initramfs -u et grub-install sur tous les disques (et de recopier la partition EFI s'il y en a).
Tu fais bien de rappeler ça, normalement on y pense mais le jour où on oublie c'est pénible. J'ai quand même l'impression que changer de serveur reste plus sécure (+plus simple +quasi sans coupure, même si ici c'est pas important) : réinstall à l'identique, copie des datas, proxy_pass de l'ancien vers le nouveau, modifs dns, reset ancien. -- Daniel Certains hommes parlent pendant leur sommeil. Les conférenciers parlent pendant le sommeil des autres. Albert Camus
Bonjour, Il arrive qu'un ou plusieurs secteurs soient défectueux sur un HDD. C'est pas anormale Par contre si celui si arrête pas d'augmenté, ben la il faut changer le disque car celui vas claquer dans pas longtemps ... Smartctl t'indique que ne peut pas lire un secteur correctement via le message 'Offline uncorrectable sectors', il s’agit problème de checksum sur ce secteur (ou bien réellement illisible). Il y a 2 possibilités : - Soit le secteur est mal écrit, donc il suffit de réécrire et relire la data derrière pour confirmer le retour à la normale. - Soit le secteur est mort, et la il faut provoquer la réallocation de celui ci par le disque lui même. Dans le cas d'un RAID, c'est le plus simple a réparer. Faire un : smartctl -a /dev/sda et smartctl -a /dev/sdc pour vérifier qu'il y a bien une erreur sur le disque. la valeur 'Offline_Uncorrectable' de chaque disque doit être supérieur a 0 si il y a erreur. Le moyen de mettre en œuvre la réallocation automatique du secteur par le disque c'est de lui faire écrire de nouveau ce secteur. Au bout de 3 échecs, le secteur est remplacé par un secteur de secours par le disque lui même. On peut tout faire à la mano mais c'est compliqué à faire. Sur un disque solo, ça revient a perdre la data sur ce secteur, alors qu'en raid on peux reconstruire cette data. Bref, la solution pour le raid et de faire vérifier / réparer les datas par le système en faisant : echo 'check' > /sys/block/mdX/md/sync_action (remplacer le X par ton numéro de raid) Cela a pour effet de vérifier l’intégralité des données sur les disques et de provoque la réalocation des secteurs défectueux: Si un secteur d'un disque est corrompu, la data est mise en mémoire (data reconstituée) et elle est réécrite sur le disque au même endroit. Si la relecture ne fonctionne pas (secteur de la data toujours défectueux), elle réécrite une nouvelle fois. au bout de 3 fois, le disque détecte l’écriture avec erreur sur le secteur et effectue par lui même le remplacement du secteur par un secteur de secours. Si il y a bien un secteur de secours libre, la data est mise sur ce nouveau secteur et il y a un remappage du secteur défectueux sur le nouveaux secteur au niveau du disque (écrit dans son EPROM). L'erreur disparait sur le disque et 'Offline_Uncorrectable' est remis a zéro et 'Reallocated_Sector_Ct' est incrémenté. Il y a une quantité très limité de secteurs libres sur le disque, donc si trop d'erreurs c'est cuit ! Si le fait de réécrire la data sur le même secteur, et que celui ci devient de nouveau lisible, il n'y a pas de réallocation et seulement 'Offline_Uncorrectable' est remis a zéro. On peux vérifier l'avancement du check avec la commande : mdadm --detail /dev/mdX (X étant le numéro de ton raid) Le check dure très longtemps car il vérifie toutes les datas et leurs allocations. Si tout ce passe bien après le check, tout est en ordre et le 'Offline_Uncorrectable' des disques est a zéro. Voila. Ludo. Le 24/01/2023 à 10:28, Daniel Caillibaud a écrit :
Le 24/01/23 à 09:06, Pierre DOLIDON <sn4ky@sn4ky.net> a écrit :
je changerait le disque aussi. la procédure chez OVH a bien changé. et est sans risque. Mmh, changer un disque sur du raid soft, c'est jamais sans risque. Et des changements de composant où c'est pas le bon qui est changé, j'en ai vu plusieurs, même si c'était y'a qq années car après plusieurs grosses galères j'ai plus jamais demandé de changement de composant, je change de machine.
le disque est changé a froid de toute manière, tu fourni le serial du disque a changer, le cat /proc/mdstat et les sorties de smartctl, et un créneau horaire pour changer le disque, et c'est fait. Avec du raid5 et deux disques sur trois ayant des pbs, le risque de crasher un autre disque à la reconstruction du raid est pas négligeable.
avant ça, chez nous la procédure est d'update-initramfs -u et grub-install sur tous les disques (et de recopier la partition EFI s'il y en a). Tu fais bien de rappeler ça, normalement on y pense mais le jour où on oublie c'est pénible.
J'ai quand même l'impression que changer de serveur reste plus sécure (+plus simple +quasi sans coupure, même si ici c'est pas important) : réinstall à l'identique, copie des datas, proxy_pass de l'ancien vers le nouveau, modifs dns, reset ancien.
-- ------------------------------------------------------------------------------------------------------------------------- Ce message inclut une signature numérique. Il certifie que l'expéditeur et le contenue du message sont authentiques. Si votre logiciel de messagerie est compatible, Il doit garantir que le document n'a pas été altéré entre l'instant où l'auteur l'a signé et le moment où le lecteur le consulte. Loi n°2000-230 du 13 mars 2000 Art. 1316, 1316-1, 1316-2, 1316-3, 1316-4 du Code civil. La présence d'un fichier joint 'smime.p7s' (fichier signature) indique que votre client messagerie n'est pas compatible. -------------------------------------------------------------------------------------------------------------------------
Le 06/02/23 à 11:38, Ludovic Levet via FRsAG <frsag@frsag.org> a écrit :
Bref, la solution pour le raid et de faire vérifier / réparer les datas par le système en faisant : echo 'check' > /sys/block/mdX/md/sync_action (remplacer le X par ton numéro de raid)
Merci pour toutes les explications, j'ai appris des trucs, je garde ce mail au chaud pour la prochaine fois ;-) (j'ai déjà changé la machine). -- Daniel Le pressentiment, c'est le souvenir du futur. Pierre Dac
participants (9)
-
Arnaud Launay -
B.B. -
Christophe BAILLON -
Daniel Caillibaud -
David Ponzone -
Ludovic Levet -
Pierre Colombier -
Pierre DOLIDON -
Xavier Beaudouin