Além do sistema de registro regular, o BTRFS possui um comando stats , que controla os erros (incluindo erros de leitura, escrita e corrupção / checksum) 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
Você pode criar um cronjob root simples:
[email protected]
@hourly /sbin/btrfs device stats /data | grep -vE ' 0$'
Isso verificará as contagens de erros positivos a cada hora e enviará um e-mail para você. 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 o BTRFS (que tem checksumming), geralmente recomenda-se agendar um scrub a cada duas semanas para detectar a corrupção silenciosa causada por um drive defeituoso.
@monthly /sbin/btrfs scrub start -Bq /data
A opção -B manterá o scrub em primeiro plano, para que você veja os resultados no cron do email que você envia. Caso contrário, ele será executado em segundo plano e você terá que lembrar de verificar os resultados manualmente, pois eles não estariam no e-mail.
Atualização : Aprimorada grep como sugerido por Michael Kjörling, obrigado.
Atualização 2 :
Notas adicionais sobre depuração versus operações de leitura regulares (isso não se aplica apenas ao BTRFS):
Como apontado por Ioan, um scrub pode levar muitas horas, dependendo do tamanho e do tipo do array (e outros fatores), até mais do que um dia em alguns casos. E é uma varredura ativa, não detectará erros futuros - o objetivo de um scrub é encontrar e corrigir erros em suas unidades naquele momento. Mas, como acontece com outros sistemas RAID, recomenda-se programar 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 corretos. Mas considere um espelho simples - se a primeira cópia do arquivo estiver danificada, talvez por uma unidade prestes a morrer, mas a segunda cópia, que está correta, for realmente lida pelo BTRFS, então o BTRFS não saberá que existe corrupção em uma das unidades. Isso ocorre simplesmente porque os dados solicitados foram recebidos, eles correspondem à soma de verificação que o BTRFS armazenou para esse arquivo, portanto, não há necessidade de o BTRFS ler a outra cópia. 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 essa operação de leitura.
Agora, vamos supor que o BTRFS só lê a partir da unidade boa, não é executado o scrub que detectaria o dano na unidade defeituosa e, em seguida, a unidade também funciona mal - o resultado seria perda de dados (pelo menos o BTRFS saberia quais arquivos ainda estão corretos e ainda permitirão que você os leia). Claro, este é um exemplo simplificado; na realidade, o BTRFS nem sempre lê uma unidade e ignora a outra.
Mas o ponto é que os scrubs periódicos são importantes porque eles encontrarão (e consertarão) erros que as operações regulares de leitura não necessariamente detectarão.
Inversores com falhas : Como essa pergunta é bastante popular, gostaria de salientar que essa "solução de monitoramento" é para detectar problemas com possivelmente discos defeituosos (por exemplo, a unidade em estado morto causando erros, mas ainda acessível).
Por outro lado, se uma unidade for repentinamente desligada (desconectada ou completamente inoperante 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 desapareceu enquanto o sistema de arquivos está montado, como apontado nesta entrada da lista de discussão de 09/2015 (é possível que isso tenha sido corrigido):
The difference is that we have code to detect a device not being present at mount, we don't have code (yet) to detect it dropping on a mounted filesystem. Why having proper detection for a device disappearing does not appear to be a priority, I have no idea, but that is a separate issue from mount behavior.
link
Haveria toneladas de mensagens de erro no dmesg até lá, então o dmesg do grepping pode não ser confiável.
Para um servidor que usa o BTRFS, pode ser uma idéia ter uma verificação personalizada (tarefa cron) que envia um alerta se pelo menos uma das unidades na matriz RAID desaparecer, ou seja, não estiver mais acessível ...