Não é possível montar o volume xfs para reproduzir o log. O que agora?

Question

O 42TB LUN, formatado em XFS e compartilhado por meio do NFS foi relatado como "indisponível" pelos clientes. No final, fui forçado a reiniciar o servidor de arquivos. O XFS LUN não será montado até que seja reparado e, para reparar, eu preciso montá-lo para que o log reproduza e confirme as alterações não confirmadas. No passado, aprendi que despejar o log e executar o reparo resulta na perda de nomes de arquivos para uma parte dos arquivos e pastas no LUN. 42 TB e potencialmente centenas de milhares de arquivos. A perda de nomes de arquivos equivale à perda de dados.

Eu tenho um backup. A restauração exigirá a coleta de recursos. Acho que há aproximadamente 30 TB de dados nesse LUN que preciso restaurar e copiar de volta no lugar. Então eu preciso de 30 TB de espaço livre, o que não está prontamente disponível.

Existe outra maneira de forçar o XFS a montar a fim de reproduzir esses logs e confirmar as alterações?

Esta é a terceira vez que eu tenho um 'congelamento' LUN em mim e ser reportado como xfs corrompido nos logs e forçado a reiniciar o servidor para trazê-lo de volta on-line. O XFS parece ter uma reputação sólida. Tem sido em torno de uma quantidade significativa de tempo. E é o padrão para o sistema operacional do servidor de arquivos (RHEL7). Eu tenho algum erro terrível na minha configuração que está matando esses LUNs?

A SAN apresenta LUN, nodev montado, nosuid, nofail no servidor de arquivos. Compartilhamento de servidor de arquivos para estações de trabalho que montam o compartilhamento como síncrono. Existe algo nessa combinação que iria travar o servidor de arquivos?

    

Answer 1

Surgiu essa questão ao verificar se há atualizações nos bugs # 1681410 e # 1686687 na barra de lançamento, que também sofri com sintomas semelhantes aos que você está descrevendo (também com o XFS, mas um LUN maior e ao executar o servidor do Ubuntu 16.04).

Estamos verificando nosso sistema de armazenamento (que fornece logs extensivos) em grande profundidade (solicitando suporte do fabricante), mas acabamos não encontrando erros ou configurações incorretas.

Depois de nos depararmos com isso várias vezes, conseguimos pregar a ocorrência desse comportamento até certo ponto em que ninguém pode ter trabalhado ativamente no sistema, o que nos permite examinar outros fatores também. Nós finalmente encontramos evidências de que as execuções agendadas pelo cron do fstrim (que é um padrão no servidor do Ubuntu 16.04!) Iniciadas uma vez por semana parecem ativar as corrupções em nosso sistema de arquivos, especialmente levando algum tempo para criar um LUN de mais de 100 TB de tamanho .

Acredito que os bugs postados na barra de lançamento descrevam bem esse problema, mas, como me parece, esse problema foi upstream, mas nunca foi consertado até agora. Então, por enquanto, nós simplesmente nos certificamos de que nenhum fstrim seja executado removendo a respectiva forma de entrada cron.weekly. Também verificamos se um cron-job foi adicionado novamente após a execução de atualizações, algo que gostaria de resolver de maneira diferente.