Além do sistema de registro regular, o BTRFS possui um comando de estatísticas , que monitora os erros (incluindo erros de leitura, gravação e corrupção / soma de verificação) por unidade:
# 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
Então você pode criar um cronjob raiz simples:
MAILTO=admin@myserver.com
@hourly /sbin/btrfs device stats /data | grep -vE ' 0$'
Isso verificará a contagem de erros positivos a cada hora e enviará um e-mail. Obviamente, você testaria esse cenário (por exemplo, causando corrupção ou removendo o grep) para verificar se a notificação por email funciona.
Além disso, com sistemas de arquivos avançados como BTRFS (com soma de verificação), é recomendável agendar uma limpeza a cada duas semanas para detectar corrupção silenciosa causada por uma unidade defeituosa.
@monthly /sbin/btrfs scrub start -Bq /data
A -Bopção manterá a limpeza em primeiro plano, para que você veja os resultados no email que o cron envia. Caso contrário, ele será executado em segundo plano e você precisará verificar os resultados manualmente, pois eles não estariam no email.
Atualização : grep aprimorado, conforme sugerido por Michael Kjörling, obrigado.
Atualização 2 : notas adicionais sobre lavagem versus operações de leitura regulares (isso não se aplica apenas ao BTRFS):
Conforme apontado por Ioan, uma limpeza pode levar muitas horas, dependendo do tamanho e tipo da matriz (e outros fatores), até mais de um dia em alguns casos. E é uma verificação ativa, que não detecta erros futuros - o objetivo de uma limpeza é encontrar e corrigir erros em suas unidades naquele momento. Mas, como em outros sistemas RAID, é recomendável agendar scrubs periódicos. É verdade que uma operação de E / S típica, como a leitura de um arquivo, verifica se os dados lidos estão realmente corretos. Mas considere um espelho simples - se a primeira cópia do arquivo estiver danificada, talvez por uma unidade que esteja prestes a morrer, mas a segunda cópia, que está correta, seja realmente lida pelo BTRFS, então o BTRFS não saberá que há corrupção em uma das unidades. Isso ocorre simplesmente porque os dados solicitados foram recebidos,Isso significa que, mesmo que você leia especificamente um arquivo que sabe estar corrompido em uma unidade, não há garantia de que a corrupção será detectada por esta operação de leitura.
Agora, vamos supor que o BTRFS apenas lê a partir da boa unidade, nenhuma limpeza é executada para detectar os danos na unidade defeituosa e, em seguida, a boa unidade também falha - o resultado seria perda de dados (pelo menos o BTRFS saberia quais arquivos ainda estão corretos e ainda permitem que você os leia). Obviamente, este é um exemplo simplificado; na realidade, o BTRFS nem sempre lê de uma unidade e ignora a outra.
Mas o ponto é que scrubs periódicos são importantes porque encontrarão (e corrigirão) erros que as operações regulares de leitura não necessariamente detectam.
Drives com falha : Como essa pergunta é bastante popular, gostaria de salientar que esta "solução de monitoramento" é para detectar problemas com possíveis discos defeituosos (por exemplo, um drive que está morrendo causando erros, mas ainda acessível).
Por outro lado, se uma unidade desaparecer repentinamente (desconectada ou completamente morta, em vez de morrer e produzir erros), seria uma unidade com falha (o ZFS marcaria essa unidade como FAULTED). Infelizmente, o BTRFS pode não perceber que uma unidade acabou enquanto o sistema de arquivos está montado, conforme apontado nesta entrada da lista de emails de 09/2015 (é possível que isso tenha sido corrigido):
A diferença é que temos código para detectar um dispositivo que não está presente na montagem, ainda não temos código para detectá-lo em um sistema de arquivos montado. Por que ter uma detecção adequada para um dispositivo desaparecendo não parece ser uma prioridade, não faço ideia, mas isso é um problema separado do comportamento da montagem.
https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg46598.html
Havia toneladas de mensagens de erro no dmesg a essa altura, portanto, grepping dmesg pode não ser confiável.
Para um servidor que usa BTRFS, pode ser uma idéia ter uma verificação personalizada (tarefa cron) que envie um alerta se pelo menos uma das unidades na matriz RAID se for, ou seja, não estiver mais acessível ...