Como você detecta um sistema de arquivos XFS com falha?

Question

Atualmente eu monitora um sistema de arquivos com falha (como resultado de um disco, controlador, qualquer que seja o problema) verificando o syslog em busca de mensagens como esta:

2017-06-15T17:18:10.081665+00:00    2017-06-15T17:18:10+00:00   localhost  kernel:  [1381844.448488] blk_update_request: critical target error, dev sdj, sector 97672656
2017-06-15T17:18:10.724329+00:00    2017-06-15T17:18:10+00:00   localhost  kernel:  [1381845.047871] XFS (md0): metadata I/O error: block 0x2baa81400 ("xlog_iodone") error 121 numblks 512
2017-06-15T17:18:10.724329+00:00    2017-06-15T17:18:10+00:00   localhost  kernel:  [1381845.124418] XFS (md0): xfs_do_force_shutdown(0x2) called from line 1177 of file /build/linux-lts-wily-8ENwT0/linux-lts-wily-4.2.0/fs/xfs/xfs_log.c.  Return address = 0xffffffffc050e100
2017-06-15T17:18:10.724349+00:00    2017-06-15T17:18:10+00:00   localhost  kernel:  [1381845.124425] XFS (md0): Log I/O Error Detected.  Shutting down filesystem
2017-06-15T17:18:10.724349+00:00    2017-06-15T17:18:10+00:00   localhost  kernel:  [1381845.124452] XFS (md0): xfs_log_force: error -5 returned.
2017-06-15T17:18:10.724354+00:00    2017-06-15T17:18:10+00:00   localhost  kernel:  [1381845.163480] XFS (md0): Please umount the filesystem and rectify the problem(s)
2017-06-15T17:18:40.612572+00:00    2017-06-15T17:18:40+00:00   localhost  kernel:  [1381875.074647] XFS (md0): xfs_log_force: error -5 returned.
2017-06-15T17:19:10.612554+00:00    2017-06-15T17:19:10+00:00   localhost  kernel:  [1381905.101606] XFS (md0): xfs_log_force: error -5 returned.
2017-06-15T17:19:40.612558+00:00    2017-06-15T17:19:40+00:00   localhost  kernel:  [1381935.128546] XFS (md0): xfs_log_force: error -5 returned.

Isso é ok mas eu realmente gostaria de uma verificação mais canônica. A única coisa em que consigo pensar é escrever um script que tente gravar um arquivo em disco e disparar um alarme se não puder, por qualquer motivo. No entanto, isso parece estar propenso a falsos positivos - há várias razões pelas quais um arquivo pode não ser capaz de ser escrito, não apenas um sistema de arquivos com falha.

Além de ler os logs ou escrever um arquivo canário no disco, como isso pode ser monitorado?

    

Answer 1

Hmmm. Como eu detecto um sistema de arquivos XFS com falha?

Estou usando o XFS há anos. Mas ... eu acho que eu não detecto nada. Se monta, eu confio que funciona. É assim que a maioria das pessoas faz isso ... verificações de sistema de arquivos são automatizadas, se ele é inicializado e pronto, é isso.

Agora, não me entenda mal. Eu realmente faço uma tonelada de monitoramento, mas nada disso é específico do sistema de arquivos. Eu executo selftests SMART (usando select,cont para fazer um segmento de disco por dia, porque long simplesmente demora muito). Eu executo cheques RAID (também em segmentos) e também verifico que não há incompatibilidades na paridade ( mismatch_cnt = 0). Recebo uma notificação por email instantâneo se algum deles falhar e eu realmente substituir os HDDs quando eles começarem a realocar setores (ou pelo menos, não mais confiar neles com dados importantes).

Portanto, tenho monitoramento para garantir que o armazenamento funcione como deveria. Isso cobre os erros dentro das próprias unidades (SMART) e, em certa medida, também os erros em um nível mais alto (as verificações de RAID também testam controladores, cabos, lógica de RAID, etc.).

Desde que funcione bem, o sistema de arquivos também ficará bem. Fora dos sistemas de arquivos checksumming como ZFS / btrfs (talvez também XFS no futuro), não é realmente parte do conceito executar verificações em um nível de sistema de arquivos enquanto montado, além de qualquer sanidade que o sistema de arquivos faz internamente.

Sua saída sugere que você está executando o RAID também e tinha um disco com falha nesse RAID; mesmo assim, isso não deve causar erros em md0 , a menos que seja RAID sem redundância (RAID0 ou RAID1 / 5/6/10 já degradado).

Você deve corrigir seus problemas abaixo da camada do sistema de arquivos primeiro. Você dificilmente pode culpar o XFS por erros de disco e não é assim que você verifica erros de disco.

Eu acho que se você realmente quisesse executar um teste de leitura completo sobre o sistema de arquivos, você poderia fazer um xfsdump para um disco de backup ... se você estivesse fazendo um teste de leitura completo do seu sistema de arquivos, também faça isso de uma maneira significativa.

É da natureza de xfsdump percorrer o sistema de arquivos XFS em sua totalidade e armazenar todos os arquivos. Então, isso deve ser o mais próximo possível de um teste de leitura completo, sem incluir espaço livre.

É claro que, se você já está executando outro sistema de backup, essa é a mesma história em um sistema independente de arquivos (e se esse sistema de backup encontrar erros de leitura que não são apenas falta de permissões, é melhor enviar um email relatório para você também), embora, claro, se for um backup incremental, sem backups completos periódicos, ele não lerá um arquivo mais de uma vez ...

Mas, em geral, confiamos que os sistemas de arquivos "apenas funcionem", desde que o armazenamento seja conhecido por funcionar. Embora seja bom ter todos os programas sem exceção para elevar todos os erros de E / S que encontrar, não tenho conhecimento de uma solução genérica para isso. Cada programa faz seu próprio tratamento de erros.