Comment surveiller les erreurs du système de fichiers BTRFS?

J'ai vu de la documentation sur un démon qui peut exécuter un programme / script pour divers événements BTRFS, mais je ne le trouve plus.

Comment puis-je exécuter un script / programme en cas de panne d'un lecteur pour une baie BTRFS raid1? Je voudrais exécuter un script sur n'importe quelle erreur pour agir comme un avertissement précoce pour un lecteur potentiellement défaillant, mais la panne réelle du lecteur est la plus importante. Je voudrais démonter le système de fichiers à ce stade (si ce n'est pas ce que fait BTRFS de toute façon) et définir une alarme.

En plus du système de journalisation normal, BTRFS a une commande stats , qui garde une trace des erreurs (y compris les erreurs de lecture, d'écriture et de corruption / somme de contrôle) par lecteur:

# btrfs device stats /
[/dev/mapper/luks-123].write_io_errs   0
[/dev/mapper/luks-123].read_io_errs    0
[/dev/mapper/luks-123].flush_io_errs   0
[/dev/mapper/luks-123].corruption_errs 0
[/dev/mapper/luks-123].generation_errs 0

Vous pouvez donc créer un cronjob racine simple:

[email protected]
@hourly /sbin/btrfs device stats /data | grep -vE ' 0$'

Cela vérifiera le nombre d'erreurs positives toutes les heures et vous enverra un e-mail. Évidemment, vous testeriez un tel scénario (par exemple en provoquant une corruption ou en supprimant le grep) pour vérifier que la notification par e-mail fonctionne.

De plus, avec les systèmes de fichiers avancés comme BTRFS (qui ont une somme de contrôle), il est souvent recommandé de planifier un nettoyage toutes les deux semaines pour détecter la corruption silencieuse causée par un mauvais lecteur.

@monthly /sbin/btrfs scrub start -Bq /data

L' -Boption gardera le gommage au premier plan, de sorte que vous verrez les résultats dans l'e-mail que cron vous envoie. Sinon, il s'exécutera en arrière-plan et vous devrez vous rappeler de vérifier les résultats manuellement car ils ne figureraient pas dans l'e-mail.

Mise à jour : grep amélioré comme suggéré par Michael Kjörling, merci.

Mise à jour 2 : Notes supplémentaires sur le nettoyage par rapport aux opérations de lecture régulières (cela ne s'applique pas uniquement à BTRFS uniquement):
Comme l'a souligné Ioan, un gommage peut prendre plusieurs heures, selon la taille et le type de la matrice (et d'autres facteurs), voire plus d'une journée dans certains cas. Et c'est une analyse active, elle ne détectera pas les erreurs futures - le but d'un nettoyage est de trouver et de corriger les erreurs sur vos disques à ce moment-là. Mais comme pour les autres systèmes RAID, il est recommandé de planifier des nettoyages périodiques. Il est vrai qu'une opération d'E / S typique, comme la lecture d'un fichier, vérifie si les données lues sont réellement correctes. Mais considérez un simple miroir - si la première copie du fichier est endommagée, peut-être par un lecteur qui est sur le point de mourir, mais la deuxième copie, qui est correcte, est en fait lue par BTRFS, alors BTRFS ne saura pas qu'il y a corruption sur l'un des disques. C'est tout simplement parce que les données demandées ont été reçues,Cela signifie que même si vous lisez spécifiquement un fichier dont vous savez qu'il est corrompu sur un lecteur, rien ne garantit que la corruption sera détectée par cette opération de lecture.
Supposons maintenant que BTRFS ne lit que sur le bon disque, aucun scrub n'est exécuté qui détecterait les dommages sur le mauvais disque, puis le bon disque se détériore également - le résultat serait une perte de données (au moins BTRFS saurait quels fichiers sont toujours corrects et vous permettront toujours de les lire). Bien sûr, ceci est un exemple simplifié; en réalité, BTRFS ne lira pas toujours d'un lecteur et ignorera l'autre.
Mais le fait est que les nettoyages périodiques sont importants car ils trouveront (et corrigeront) des erreurs que les opérations de lecture régulières ne détecteront pas nécessairement.

Lecteurs défectueux : Étant donné que cette question est très populaire, je voudrais souligner que cette «solution de surveillance» est destinée à détecter les problèmes avec des lecteurs potentiellement mauvais (par exemple, un lecteur mourant provoquant des erreurs mais toujours accessible).

D'un autre côté, si un disque est soudainement parti (déconnecté ou complètement mort plutôt que de mourir et de produire des erreurs), ce serait un disque défectueux (ZFS marquerait un tel disque comme FAULTED). Malheureusement, BTRFS peut ne pas réaliser qu'un lecteur a disparu pendant que le système de fichiers est monté, comme indiqué dans cette entrée de liste de diffusion de 09/2015 (il est possible que cela ait été corrigé):

La différence est que nous avons du code pour détecter un périphérique qui n'est pas présent au montage, nous n'avons pas (encore) de code pour le détecter tombant sur un système de fichiers monté. Pourquoi la détection appropriée de la disparition d'un périphérique ne semble pas être une priorité, je n'en ai aucune idée, mais c'est un problème distinct du comportement de montage.

https://www.mail-archive.com/[email protected]/msg46598.html

Il y aurait des tonnes de messages d'erreur dans dmesg à ce moment-là, donc le fait de saluer dmesg pourrait ne pas être fiable.
Pour un serveur utilisant BTRFS, cela pourrait être une idée d'avoir une vérification personnalisée (tâche cron) qui envoie une alerte si au moins l'un des disques de la matrice RAID est parti, c'est-à-dire qu'il n'est plus accessible ...

À partir de btrfs-progs v4.11.1, stats a l'option --check qui retournera non nul si l'une des valeurs n'est pas nulle, supprimant la nécessité de l'expression régulière.

statistiques de l'appareil -c /

Je ne compterais pas sur la commande stats pour la notification d'erreur, car cette commande ne renvoie aucune erreur si un lecteur disparaît soudainement. Vous pouvez le tester en déconnectant un câble SATA ou en tirant sur un lecteur - non recommandé avec un système de fichiers important.

btrfs device stats /

Après un redémarrage, btrfs affiche les lecteurs manquants, mais cela peut être trop tard.

btrfs fi show

Il ne semble pas y avoir de démon ou d'utilitaire qui signale officiellement les événements BTRFS pour la gestion des utilisateurs. L'alternative la plus proche consiste à surveiller le journal système pour les messages de BTRFS et à réagir en conséquence.

http://marc.merlins.org/perso/btrfs/post_2014-03-19_Btrfs-Tips_-Btrfs-Scrub-and-Btrfs-Filesystem-Repair.html

Le lien ci-dessus fournit plus de détails sur la configuration d'un script ( secpackage sur Debian ou SEC ) conçu pour la surveillance des journaux à usage général afin d'agir sur les messages de journaux inattendus concernant BTRFS. Cela dépend également d'avoir un nettoyage régulier du système de fichiers pour vérifier la bit-rot et émettre des entrées de journal comme mesure préventive. Voici un extrait spécifique au script SEC:

Comment configurer sec, corrélateur d'événements pour signaler les erreurs ou avertissements du système de fichiers btrfs

Après avoir installé sec.pl (apt-get install sec sur debian ou http://simple-evcorr.sourceforge.net/ ), installez les 2 fichiers de configuration ci-dessous.

Ce n'est pas infaillible, il repose sur une expression régulière de messages connus qui sont corrects et signale tous les messages inconnus. Vous pouvez étendre le regex négatif prospectif au besoin.

polgara:~\# cat /etc/default/sec  
\#Defaults for sec  
RUN_DAEMON="yes"  
DAEMON_ARGS="-conf=/etc/sec.conf -input=/var/log/syslog -pid=/var/run/sec.pid -detach -log=/var/log/sec.log"

polgara:~# cat /etc/sec.conf  
\# http://simple-evcorr.sourceforge.net/man.html  
\# http://sixshooter.v6.thrupoint.net/SEC-examples/article.html  
\# http://sixshooter.v6.thrupoint.net/SEC-examples/article-part2.html  
type=SingleWithSuppress  
ptype=RegExp  
pattern=(?i)kernel.*btrfs: (?!disk space caching is enabled|use ssd allocation|use .* compression|unlinked .* orphans|turning on discard|device label .* devid .* transid|detected SSD devices, enabling SSD mode|has skinny extents|device label|creating UUID tree|checking UUID tree|setting .* feature flag|bdev.* flush 0, corrupt 0, gen 0)  
window=60  
desc=Btrfs unexpected log  
action=pipe '%t: $0' /usr/bin/mail -s "sec: %s" root

Cela ressemble à une tâche de surveillance du système. Il existe une vérification qui implémente l'API Nagios Plugin appelée: check_btrfs . Comme vous pouvez le voir dans le code source, il a une fonction appelée check_dev_statsqui vérifie les statistiques de l'appareil et deviendra critique si l'une des valeurs n'est pas nulle. Il vérifie également les problèmes d'allocation. Ce qui n'est pas clair, c'est comment le contrôle se comporte si un disque est absent ou se déconnecte .

PS: Le plugin est empaqueté dans Debian: monitoring-plugins-btrfs