Vi alguma documentação sobre um daemon que pode executar um programa/script para vários eventos BTRFS, mas não consigo mais encontrá-la.
Como posso executar um script/programa em uma falha de unidade para uma matriz BTRFS raid1? Gostaria de executar um script em qualquer erro para atuar como um aviso antecipado de uma unidade com potencial de falha, mas a falha real da unidade é o mais importante. Eu gostaria de desmontar o sistema de arquivos nesse ponto (se não for isso que o BTRFS faz) e definir um alarme.
Responder1
Além do sistema de registro regular, o BTRFS possui umEstatísticascomando, que monitora 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ê poderia criar um cronjob raiz simples:
[email protected]
@hourly /sbin/btrfs device stats /data | grep -vE ' 0$'
Isso verificará contagens de erros positivas a cada hora e enviará um e-mail para você. Obviamente, você testaria tal 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 possuem soma de verificação), geralmente é recomendado 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á o esfregaço em primeiro plano, para que você veja os resultados no e-mail que o cron lhe enviar. Caso contrário, ele será executado em segundo plano e você terá que se lembrar de verificar os resultados manualmente, pois eles não estarão no e-mail.
Atualizar: Grep aprimorado conforme sugerido por Michael Kjörling, obrigado.
Atualização 2: Notas adicionais sobre operações de limpeza versus operações regulares de leitura (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, não detectará erros futuros - o objetivo de uma limpeza é encontrar e corrigir erros em suas unidades naquele momento. Mas, como acontece com outros sistemas RAID, é recomendável agendar limpezas periódicas. É verdade que uma operação típica de E/S, 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 está prestes a morrer, mas a segunda cópia, que está correta, for 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 e correspondem à soma de verificação que o BTRFS armazenou para este arquivo, portanto, não há necessidade do 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 esta operação de leitura.
Agora, vamos supor que o BTRFS só lê a unidade boa, nenhuma limpeza é executada para detectar o dano na unidade ruim e, em seguida, a unidade boa também fica ruim - 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 a questão é que as limpezas periódicas são importantes porque encontrarão (e corrigirão) erros que as operações regulares de leitura não necessariamente detectarão.
Unidades com falha: Como esta pergunta é bastante popular, gostaria de salientar que esta "solução de monitoramento" serve para detectar problemas com unidades possivelmente defeituosas (por exemplo, unidade 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 desapareceu enquanto o sistema de arquivos está montado, conforme apontado nesta entrada da lista de discussão 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, não temos código (ainda) para detectá-lo caindo em um sistema de arquivos montado. Por que a detecção adequada do desaparecimento de um dispositivo não parece ser uma prioridade, não tenho ideia, mas esse é um problema separado do comportamento de montagem.
https://www.mail-archive.com/[e-mail protegido]/msg46598.html
Haveria toneladas de mensagens de erro no dmesg naquela época, então usar o grepping dmesg pode não ser confiável.
Para um servidor que usa BTRFS, pode ser uma ideia ter uma verificação personalizada (cron job) que envia um alerta se pelo menos uma das unidades da matriz RAID desaparecer, ou seja, não estiver mais acessível...
Responder2
A partir do btrfs-progs v4.11.1 stats tem a opção --check que retornará diferente de zero se algum dos valores não for zero, eliminando a necessidade do regex.
device stats -c /
Responder3
Eu não confiaria no comando stats para notificação de erros, porque esse comando não retornará nenhum erro se uma unidade desaparecer repentinamente. Você pode testá-lo desconectando um cabo SATA ou puxando uma unidade - não recomendado com um sistema de arquivos importante.
btrfs device stats /
Após uma reinicialização, o btrfs mostra unidades ausentes, mas isso pode ser tarde demais.
btrfs fi show
Responder4
Parece uma tarefa de monitoramento do sistema. Existe uma verificação que implementa a API do plugin Nagios chamada:check_btrfs. Como você pode ver no código-fonte, ele possui uma função chamada check_dev_statsque verifica as estatísticas do dispositivo e ficará crítica se algum dos valores for diferente de zero. Ele também verifica problemas de alocação. O que permanece obscuro écomo a verificação se comporta se um disco estiver ausente ou ficar offline.
PS: O plugin é empacotado no Debian:plug-ins de monitoramento-btrfs