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.