Además del sistema de registro regular, BTRFS tiene un estadísticas Comando, 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ía crear un cronjob raíz simple:
[email protected]
@hourly /sbin/btrfs device stats /data | grep -vE ' 0$'
Esto verificará los recuentos de errores positivos cada hora y le enviará un correo electrónico. Obviamente, probaría tal escenario (por ejemplo, causando daños o eliminando 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 una limpieza cada dos semanas para detectar corrupción silenciosa causada por una unidad defectuosa.
@monthly /sbin/btrfs scrub start -Bq /data
El -B La opción mantendrá la limpieza en primer plano, de modo que verás los resultados en el correo electrónico que te envíe el 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 regulares de lectura (esto no solo se aplica solo a BTRFS):
Como señaló Ioan, una limpieza puede llevar muchas horas, según el tamaño y el tipo de 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 borrado 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 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, es realmente leída por BTRFS, entonces BTRFS no sabrá que hay corrupción. en una de las unidades. Esto se debe simplemente a que se recibieron los datos solicitados, 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 el disco bueno, no se ejecuta ninguna corrección que detecte el daño en el disco malo, y luego el disco bueno 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 regulares de lectura 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 (p.
Por otro lado, si una unidad desaparece repentinamente (desconectada o completamente muerta en lugar de morir y producir errores), sería una unidad con fallas (ZFS marcaría dicha unidad como DEFECTUOSA). Desafortunadamente, es posible que BTRFS no se dé cuenta de que una unidad se ha ido mientras el sistema de archivos está montado, como se indica en esta entrada de la lista de correo del 09/2015 (es posible que se haya reparado):
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 detectarlo cayendo en un sistema de archivos montado. Por qué tener una detección adecuada para la desaparición de un dispositivo no parece ser una prioridad, no tengo idea, pero eso 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 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 en la matriz RAID no está, es decir, ya no está accesible...
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.
estadísticas del dispositivo -c
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 tirando de una unidad; no se recomienda con un sistema de archivos importante.
btrfs device stats /
Después de reiniciar, btrfs muestra que faltan unidades, pero puede que sea demasiado tarde.
btrfs fi show