¿Cómo monitorear la incursión del sistema de archivos BTRFS en busca de errores?

Vi algo de documentación sobre un demonio que puede ejecutar un programa / script para varios eventos BTRFS, pero ya no puedo encontrarlo.

¿Cómo puedo hacer que se ejecute un script / programa en un fallo de unidad para una matriz BTRFS raid1? Me gustaría ejecutar un script en cualquier error para actuar como una advertencia temprana para una unidad potencialmente defectuosa, pero la falla real de la unidad es lo más importante. Me gustaría desmontar el sistema de archivos en ese punto (si eso no es lo que BTRFS hace de todos modos) y configurar una alarma.

Además del sistema de registro regular, BTRFS tiene un comando de estadísticas , que realiza un seguimiento de los errores (incluidos los errores de lectura, escritura y corrupción / suma de verificación) por unidad:

# 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

Para que pueda crear un cronjob raíz simple:

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

Esto verificará el conteo de errores positivos cada hora y le enviará un correo electrónico. Obviamente, probaría este escenario (por ejemplo, al causar corrupción o eliminar el grep) para verificar que la notificación por correo electrónico funciona.

Además, con sistemas de archivos avanzados como BTRFS (que tienen suma de verificación), a menudo se recomienda programar un fregado cada dos semanas para detectar la corrupción silenciosa causada por un disco defectuoso.

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

La -Bopción mantendrá el exfoliante en primer plano, para que pueda ver los resultados en el correo electrónico que le envía cron. De lo contrario, se ejecutará en segundo plano y deberá recordar comprobar los resultados manualmente, ya que no aparecerían en el correo electrónico.

Actualización : grep mejorado según lo sugerido por Michael Kjörling, gracias.

Actualización 2 : Notas adicionales sobre el fregado frente a las operaciones de lectura regular (esto no solo se aplica a BTRFS):
Como lo señaló Ioan, un exfoliante puede tomar muchas horas, dependiendo del tamaño y tipo de la matriz (y otros factores), incluso más de un día en algunos casos. Y es un escaneo activo, no detectará errores futuros: el objetivo de un exfoliante es encontrar y corregir errores en sus unidades en ese momento. Pero como con otros sistemas RAID, se recomienda programar matorrales periódicos. Es cierto que una operación de E / S típica, como leer un archivo, verifica si los datos que se leyeron son realmente correctos. Pero considere un espejo simple: si la primera copia del archivo está dañada, tal vez por una unidad que está a punto de morir, pero la segunda copia, que es correcta, en realidad es leída por BTRFS, entonces BTRFS no sabrá que hay corrupción en una de las unidades. Esto es simplemente porque se han recibido los datos solicitados,Esto significa que incluso si lee específicamente un archivo que sabe que está dañado en una unidad, no hay garantía de que esta operación de lectura detecte el daño.
Ahora, supongamos que BTRFS solo lee desde el disco bueno, no se ejecuta ningún fregado que detecte el daño en el disco defectuoso, y luego el disco bueno también falla: el resultado sería la pérdida de datos (al menos BTRFS lo sabría qué archivos siguen siendo correctos y aún le permitirán leerlos). Por supuesto, este es un ejemplo simplificado; en realidad, BTRFS no siempre leerá de una unidad e ignorará la otra.
Pero el punto es que los scrubs periódicos son importantes porque encontrarán (y corregirán) errores que las operaciones de lectura regulares no necesariamente detectarán.

Unidades defectuosas : como esta pregunta es bastante popular, me gustaría señalar que esta "solución de monitoreo" es para detectar problemas con posibles unidades defectuosas (p. Ej., Una unidad que está muriendo y que causa errores pero aún es accesible).

Por otro lado, si una unidad desaparece repentinamente (desconectada o completamente muerta en lugar de morir y producir errores), sería una unidad defectuosa (ZFS marcaría dicha unidad como FALLIDA). Desafortunadamente, BTRFS puede no darse cuenta de que una unidad se ha ido mientras el sistema de archivos está montado, como se señala en esta entrada de la lista de correo del 09/2015 (es posible que esto haya sido parcheado):

La diferencia es que tenemos código para detectar un dispositivo que no está presente en el montaje, no tenemos código (todavía) para detectar que cae en un sistema de archivos montado. Por qué no es prioritario tener una detección adecuada de la desaparición de un dispositivo, no tengo idea, pero ese es un problema separado del comportamiento de montaje.

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

Habría toneladas de mensajes de error en dmesg en ese momento, por lo que greps dmesg podría no ser confiable.
Para un servidor que usa BTRFS, podría ser una idea tener una verificación personalizada (trabajo cron) que envíe una alerta si al menos una de las unidades en la matriz RAID ha desaparecido, es decir, ya no es accesible ...

A partir de btrfs-progs v4.11.1 stats tiene la opción --check que devolverá un valor distinto de cero si alguno de los valores no es cero, eliminando la necesidad de la expresión regular.

estadísticas del dispositivo -c /

No confiaría en el comando de estadísticas para la notificación de errores, porque este comando no devuelve ningún error si una unidad desaparece repentinamente. Puede probarlo desconectando un cable sata o extrayendo una unidad, lo que no se recomienda con un sistema de archivos importante.

btrfs device stats /

Después de reiniciar, btrfs muestra las unidades faltantes, pero eso puede ser demasiado tarde.

btrfs fi show

No parece haber un demonio o una utilidad que informe oficialmente eventos BTRFS para el manejo del usuario. La alternativa más cercana es monitorear el registro del sistema en busca de mensajes de BTRFS y reaccionar en consecuencia.

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

El enlace anterior proporciona más detalles para configurar un script ( secpaquete en Debian o SEC ) diseñado para la supervisión de registros de propósito general para actuar sobre mensajes de registro inesperados relacionados con BTRFS. También depende de tener un fregado programado regularmente del sistema de archivos para verificar la rotura de bits y emitir entradas de registro como medida preventiva. A continuación se muestra un extracto específico del script SEC:

Cómo configurar sec, correlacionador de eventos para informar errores o advertencias del sistema de archivos btrfs

Después de instalar sec.pl (apt-get install sec en debian o http://simple-evcorr.sourceforge.net/ ), instale los 2 archivos de configuración a continuación.

Esto no es infalible, se basa en una expresión regular de mensajes conocidos que están bien, e informa todos los mensajes desconocidos. Puede extender la expresión regular negativa hacia adelante según sea necesario.

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

Suena como una tarea para el monitoreo del sistema. Existe una comprobación que implementa la API de complementos de Nagios llamada: check_btrfs . Como puede ver en el código fuente, tiene una función llamada check_dev_statsque verifica las estadísticas del dispositivo y será crítico si alguno de los valores no es cero. También verifica los problemas de asignación. Lo que no está claro es cómo se comporta la verificación si un disco está ausente o se desconecta .

PD: El complemento está empaquetado en Debian: tracking-plugins-btrfs