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