En plus du système de journalisation régulier, BTRFS a un stats commande, 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 une tâche cron 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 testerez 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 des systèmes de fichiers avancés comme BTRFS (qui ont une somme de contrôle), il est souvent recommandé de programmer un nettoyage toutes les deux semaines pour détecter la corruption silencieuse causée par un mauvais disque.
@monthly /sbin/btrfs scrub start -Bq /data
Le -B gardera le scrub 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 figureront pas dans l'e-mail.
Mettre à jour :Grep amélioré comme suggéré par Michael Kjörling, merci.
Mise à jour 2 :Remarques 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 réseau (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 précis. Mais comme pour les autres systèmes RAID, il est recommandé de programmer 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 que 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 simplement parce que les données demandées ont été reçues, elles correspondent à la somme de contrôle que BTRFS a stockée pour ce fichier, il n'est donc pas nécessaire que BTRFS lise l'autre copie. 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.
Maintenant, supposons que BTRFS ne lit que depuis le bon disque, aucun nettoyage n'est exécuté pour détecter les dommages sur le mauvais disque, puis le bon disque devient également mauvais - 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 entendu, il s'agit d'un exemple simplifié; en réalité, BTRFS ne lira pas toujours à partir 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 assez populaire, j'aimerais souligner que cette "solution de surveillance" est destinée à détecter les problèmes avec des disques éventuellement défectueux (par exemple, un disque mourant provoquant des erreurs mais toujours accessible).
D'un autre côté, si un lecteur est soudainement parti (déconnecté ou complètement mort plutôt que de mourir et de produire des erreurs), il s'agirait d'un lecteur défectueux (ZFS marquerait un tel lecteur comme DÉFECTUEUX). Malheureusement, BTRFS peut ne pas se rendre compte qu'un lecteur est parti pendant que le système de fichiers est monté, comme indiqué dans cette entrée de liste de diffusion du 09/2015 (il est possible que cela ait été corrigé) :
La différence est que nous avons du code pour détecter qu'un périphérique n'est pas présent au montage, nous n'avons pas (encore) de code pour le détecter tomber sur un système de fichiers monté. Pourquoi avoir une bonne détection d'un périphérique qui disparaît 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 grepping dmesg pourrait ne pas être fiable.
Pour un serveur utilisant BTRFS, il peut être judicieux d'avoir une vérification personnalisée (tâche cron) qui envoie une alerte si au moins 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, les statistiques ont l'option --check qui renverra une valeur différente de zéro si l'une des valeurs n'est pas nulle, supprimant ainsi le besoin de la regex.
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