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:
MAILTO=admin@myserver.com
@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/linux-btrfs@vger.kernel.org/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 ...