Monitorando a integridade do sistema de arquivos XFS no Linux

Question

Recentemente, experimentei um colapso do sistema de arquivos. Eu tinha um servidor rodando por cerca de 180 dias sem parar sem nenhum problema, mas então eu notei coisas estranhas acontecendo e aparentemente o sistema de arquivos ext3 estava em péssimo estado. Eu tinha as unidades e a memória testadas e elas estavam todas bem. Em última análise, fui forçado a mangueira do sistema e fazer uma reinstalação completa. fsck.ext3 só piorou as coisas.

Agora, eu não quero que isso aconteça novamente, então desta vez eu fui com o XFS, o que eu sinto é mais maduro que o ext3, mas eu estou perdido como monitorar a saúde do sistema de arquivos. xfs_check simplesmente não me deixa escanear o dispositivo enquanto ele está montado.

Então, como você monitora a integridade de um sistema de arquivos XFS enquanto o sistema está online?

    

Answer 1

Na verdade, não há muito o que fazer para monitorar a integridade operacional do próprio sistema de arquivos. Este tópico explica as razões pelas quais você não pode executar uma verificação no estilo fsck em um sistema de arquivos on-line como leitura / gravação.

Em parte, você deve confiar que, como um sistema de arquivos journalling, o XFS está fazendo o melhor para manter seus dados em boa saúde. Você também pode se consolar sabendo que xfs_check é muito mais rápido que fsck.ext3 e o XFS não estipula verificações periódicas da mesma maneira que a regra de 180 dias / x de ext3.

Editar para comentários:

Embora eu entenda que você já foi mordido, duas vezes tímido. Posso assegurar-lhe que a "fusão completa" não é um problema sistemático associado aos sistemas de arquivos UNIX. Na minha experiência, tais eventos tendem a se materializar apenas com falha de hardware, erro do usuário (sem intenção de desrespeito) ou uma mistura infeliz de ambos. No entanto, é difícil raciocinar com você em um nível técnico sem alguns detalhes muito específicos do que deu errado com sua instalação anterior do ext3.

    

Answer 2

Coloque o sistema de arquivos em um volume lógico LVM , crie um snapshot temporário a partir do volume lógico e então fsck este snapshot (enquanto o volume lógico ainda estiver online). / p>

Talvez o script e2croncheck de Theodore Ts'o para o ext3 faça você começar.

(Como 3dinfluence mencionado: ZFS é definitivamente a melhor solução ...)

    

Answer 3

I noticed weird stuff happen

O problema não é o sistema de arquivos (ou pelo menos é extremamente improvável). O ext3 é um dos FS mais usados e qualquer bug grave o suficiente para causar corrupção catastrófica já deveria ter sido encontrado e corrigido.

A causa está em outro lugar, possivelmente no próprio hardware (talvez a RAM).

Para responder à sua pergunta: você pode verificar o sistema de arquivos XFS online, mas somente se ele estiver montado somente para leitura.

    

Answer 4

Verificar a consistência de qualquer sistema de arquivos atualmente montado simplesmente NÃO é recomendado.

    

Answer 5

Aviso: Eu amo o XFS e sua velocidade. Isso não é tanto um desabafo como é um aviso.

Resposta imediata: não, você precisará desmontar o sistema de arquivos para executar a verificação. Executar um fsck em um sistema de arquivos ao vivo é uma coisa ruim. O sistema de arquivos está constantemente mudando debaixo de tal exame, o que significa que você nunca pode realmente ter certeza se está sendo constantemente examinado, ou pior, se seus "reparos" não vão piorar.

Embora esta não seja uma resposta direta , é clara. Ext3 é provavelmente uma opção melhor para você e, se você experimentando corrupção com Ext3, então você vai querer reexaminar seu hardware. Pelo amor de $ {DIETY}, você não deveria estar usando o XFS se você está procurando algo que ganhou (potencialmente) dados frouxos durante a recuperação. Sob certas circunstâncias zerará os blocos de dados durante a recuperação .

Citado no link 2:

5.1 Write Failures

Data: We see that data errors are mostly ignored or little action is taken other than informing the user of the error. In most cases data loss occurs silently without the knowledge of the user.

Tenha em mente que o XFS foi originalmente projetado com o trabalho em vídeo em mente, então se você tivesse um arquivo de vídeo danificado, não seria grande coisa, você poderia sempre emendar vídeo para corrigir o "ponto ruim"; esperar alguns dias por um fsck em um sistema de arquivos de 14 terabytes foi um grande negócio, então ele troca o tempo de verificação pela integridade dos dados.

    

Answer 6

Corrupções do sistema de arquivos acontecem independentemente do sistema de arquivos que você está usando. Eu tive os sistemas de arquivos Ext3 e XFS indo para o sul em mim ao longo dos anos.

O ZFS, embora não esteja disponível no Linux, além de usar o FUSE, possui uma limpeza de plano de fundo on-line que pode detectar e reparar erros antes que você encontre perda de dados. Ele também faz muito ECC em todas as operações do sistema de arquivos e deve detectar e relatar quaisquer erros encontrados. No entanto, deve ser capaz de recuperar e curar-se da maioria deles. Mas mesmo com todos os truques de ECC que o ZFS faz, existem alguns casos extremos, normalmente problemas de hardware, nos quais um sistema de arquivos ZFS foi corrompido.

A melhor coisa a fazer é ter uma boa estratégia de backup e o plano de DR em vigor. A restauração de dados de um backup conhecido é a maneira mais rápida de se recuperar desses tipos de problemas. Passar por lost+found é um processo doloroso e propenso a erros.