Vi documentación sobre un demonio que puede ejecutar un programa/script para varios eventos BTRFS, pero ya no puedo encontrarla.
¿Cómo puedo ejecutar un script/programa en caso de falla de una unidad para una matriz BTRFS raid1? Me gustaría ejecutar un script ante cualquier error para que actúe como una advertencia temprana de 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 momento (si eso no es lo que hace BTRFS de todos modos) y configurar una alarma.
Respuesta1
Además del sistema de registro habitual, BTRFS tiene unestadísticascomando, que realiza un seguimiento de los errores (incluidos los errores de lectura, escritura y corrupción/suma de comprobació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
Entonces podrías crear un cronjob raíz simple:
[email protected]
@hourly /sbin/btrfs device stats /data | grep -vE ' 0$'
Esto comprobará si hay recuentos de errores positivos cada hora y le enviará un correo electrónico. Obviamente, probaría tal escenario (por ejemplo, causando corrupción o eliminando el grep) para verificar que la notificación por correo electrónico funcione.
Además, con sistemas de archivos avanzados como BTRFS (que tienen suma de verificación), a menudo se recomienda programar una limpieza cada dos semanas para detectar daños silenciosos causados por un disco defectuoso.
@monthly /sbin/btrfs scrub start -Bq /data
La -Bopción mantendrá la limpieza en primer plano, de modo que verá los resultados en el correo electrónico que le envíe cron. De lo contrario, se ejecutará en segundo plano y deberá recordar verificar los resultados manualmente, ya que no estarán en el correo electrónico.
Actualizar: Grep mejorado según lo sugerido por Michael Kjörling, gracias.
Actualización 2: Notas adicionales sobre la limpieza frente a las operaciones de lectura regulares (esto no se aplica solo a BTRFS):
Como señaló Ioan, una limpieza puede llevar 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 escaneo es encontrar y corregir errores en sus unidades en ese momento. Pero al igual que con otros sistemas RAID, se recomienda programar limpiezas periódicas. Es cierto que una operación de E/S típica, como leer un archivo, verifica si los datos leídos 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 BTRFS lee la segunda copia, que es correcta, entonces BTRFS no sabrá que hay corrupción. en una de las unidades. Esto se debe simplemente a que se recibieron los datos solicitados y coinciden con la suma de verificación que BTRFS ha almacenado para este archivo, por lo que no es necesario que BTRFS lea la otra copia.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 la corrupción.
Ahora, supongamos que BTRFS solo lee desde la unidad buena, no se ejecuta ninguna limpieza que detecte el daño en la unidad mala, y luego la unidad buena también se estropea; el resultado sería la pérdida de datos (al menos BTRFS 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á desde una unidad e ignorará la otra.
Pero el punto es que las limpiezas periódicas son importantes porque encontrarán (y corregirán) errores que las operaciones de lectura regulares no necesariamente detectarán.
Unidades defectuosas: Dado que esta pregunta es bastante popular, me gustaría señalar que esta "solución de monitoreo" es para detectar problemas con unidades posiblemente defectuosas (por ejemplo, una unidad agonizante que causa errores pero aún es accesible).
Por otro lado, si una unidad desaparece repentinamente (se desconecta o está completamente muerta en lugar de morir y producir errores), sería una unidad defectuosa (ZFS marcaría dicha unidad como FALLADA). Desafortunadamente, es posible que BTRFS no se dé cuenta de que una unidad ha desaparecido 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 que un dispositivo no está presente en el montaje, no tenemos código (todavía) para detectar que se coloca en un sistema de archivos montado. No tengo idea de por qué tener una detección adecuada de la desaparición de un dispositivo no parece ser una prioridad, pero ese es un problema separado del comportamiento de montaje.
https://www.mail-archive.com/[correo electrónico protegido]/msg46598.html
Habría toneladas de mensajes de error en dmesg en ese momento, por lo que grepping 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 de la matriz RAID ha desaparecido, es decir, ya no se puede acceder a ella...
Respuesta2
A partir de btrfs-progs v4.11.1, las estadísticas tienen 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.
device stats -c /
Respuesta3
No confiaría en el comando stats 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; no se recomienda con un sistema de archivos importante.
btrfs device stats /
Después de reiniciar, btrfs muestra unidades faltantes, pero puede que sea demasiado tarde.
btrfs fi show
Respuesta4
Suena como una tarea para monitorear el sistema. Existe una verificación que implementa la API del complemento 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ítica si alguno de los valores no es cero. También comprueba si hay problemas de asignación. Lo que no queda claro escómo se comporta la verificación si un disco falta o se desconecta.
PD: el complemento está empaquetado en Debian:complementos-de-monitoreo-btrfs