Q: MDADM mismatch_cnt> 0. Est-il possible d'identifier les blocs en désaccord?

D'accord. Après un nettoyage de routine, mon MDADM RAID5 signale mismatch_cnt = 16. Si je comprends bien, cela signifie que même si aucun périphérique n'a signalé d'erreur de lecture, il y a 16 blocs pour lesquels les données et la parité ne sont pas d'accord.

Question # 1: Peut-on obtenir une liste de ces blocs?

Question # 2: En supposant que # 1 est possible, étant donné que le système de fichiers sous-jacent est EXT4, existe-t-il un moyen d'identifier les fichiers associés à ces blocs?

J'ai des sauvegardes quasi en ligne et, dans un monde idéal, je pourrais simplement faire la différence entre la baie en direct et les données de sauvegarde pour localiser tous les fichiers qui sont devenus silencieusement corrompus. Mais la réalité est que le rappel de 6 To de données de sauvegarde serait à la fois prohibitif et long. Savoir où chercher et quoi récupérer simplifierait grandement les choses.

(Je dois noter que je n'exécute le scrub RAID qu'avec l'option 'check'. Exécuter le scrub avec l'option 'repair' semble terriblement dangereux parce que MDADM sait seulement que les données ou la parité sont incorrectes mais il ne sait pas lesquelles. Il semble donc qu'il y ait 50% de chances que MDADM devine mal et reconstruise des données incorrectes. D'où mon désir de savoir quels fichiers sont potentiellement affectés afin que je puisse les restaurer à partir d'une sauvegarde, si nécessaire)

Toutes suggestions grandement appréciées!

linux mdadm

— arcasinky
source

vérifier dmesgou / var / log / syslog?

— psusi

Salut. Autant que je sache, les seuls messages enregistrés dans syslog par le scrubber étaient les messages de démarrage et d'arrêt. Aucun message concernant les incompatibilités n'a été enregistré.

— arcasinky

Voir icheck+ ncheckdans debugfspour identifier les fichiers en fonction du décalage de secteur.

— sch

J'ai essayé d'ajouter la journalisation pour le numéro de secteur. Maintenant j'essaye de comprendre quoi faire ensuite: unix.stackexchange.com/questions/266432/…

— Peter Cordes

Je sais que rien ne dit que les disques sont mauvais, mais vérifiez-les. Utilisez le package smartmontools pour le faire pour chaque disque (comme dans smartctl -a /dev/sdaet ainsi de suite), ou utilisez toute autre méthode dont vous disposez pour exécuter un court test SMART sur chaque disque et imprimer un rapport complet. Il est très probable que l'un d'entre eux soit en train de mourir, et il faut beaucoup de mal pour déclencher une alarme de santé SMART globale.

— Spooler

Désolé, 'check' réécrit en effet dans le tableau lorsqu'il rencontre une erreur - voir https://www.apt-browse.org/browse/ubuntu/trusty/main/amd64/mdadm/3.2.5-5ubuntu4/file /usr/share/doc/mdadm/README.checkarray

'check' est une opération en lecture seule, même si les journaux du noyau peuvent suggérer le contraire (par exemple / proc / mdstat et plusieurs messages du noyau mentionneront "resync"). Veuillez également consulter la question 21 de la FAQ.

Si, cependant, lors de la lecture, une erreur de lecture se produit, la vérification déclenche la réponse normale aux erreurs de lecture qui est de générer les données «correctes» et d'essayer de les écrire - il est donc possible qu'une «vérification» déclenche une écrire. Cependant, en l'absence d'erreurs de lecture, il est en lecture seule.

... il est donc peut-être déjà trop tard pour collecter les données que vous recherchez, désolé.

À plus long terme, il convient de noter que RAID5 (et 6 et 1) n'ont aucune protection contre la pourriture des bits, ce qui est probablement la situation que vous avez rencontrée. Lorsque les données d'un disque se détériorent, elles n'ont aucun moyen de déterminer laquelle des données est bonne ou mauvaise. Je suggérerais de planifier la migration vers un système de fichiers qui additionne chaque disque comme btrfs ou zfs.

(RAID-5 ne devrait vraiment pas être utilisé dans de nouveaux déploiements - et ne devrait vraiment pas l'être lorsque la capacité des disques bruts dépasse chacun 2 To - voir http://www.zdnet.com/article/why-raid-5- cesse de travailler en 2009 / )

— Andrew W
source