Capítulo 7. Diagnosticar e corrigir problemas com os sistemas de arquivo GFS2

A função GFS2 withdraw é uma característica de integridade de dados do sistema de arquivos GFS2 que evita possíveis danos ao sistema de arquivos devido a hardware ou software do kernel defeituoso. Se o módulo de kernel GFS2 detectar uma inconsistência ao usar um sistema de arquivo GFS2 em um determinado nó de cluster, ele se retira do sistema de arquivo, deixando-o indisponível para aquele nó até que seja desmontado e remontado (ou a máquina que detecta o problema seja reinicializada). Todos os outros sistemas de arquivo GFS2 montados permanecem totalmente funcionais naquele nó. (A função de retirada do GFS2 é menos severa do que um pânico no núcleo, o que faz com que o nó seja cercado)

As principais categorias de inconsistência que podem causar uma retirada do GFS2 são as seguintes:

Um exemplo de uma inconsistência que causaria uma retirada do GFS2 é uma contagem de blocos incorreta para o inode de um arquivo. Quando o GFS2 apaga um arquivo, ele remove sistematicamente todos os blocos de dados e metadados referenciados por aquele arquivo. Quando feito, ele verifica a contagem de blocos do inode. Se a contagem de blocos não for 1 (significando que tudo o que resta é o próprio inode do disco), isso indica uma inconsistência do sistema de arquivo, uma vez que a contagem de blocos do inode não correspondeu aos blocos reais usados para o arquivo.

Em muitos casos, o problema pode ter sido causado por hardware defeituoso (memória defeituosa, placa-mãe, HBA, drives de disco, cabos, e assim por diante). Pode também ter sido causado por um bug no kernel (outro módulo do kernel sobregravando acidentalmente a memória do GFS2), ou por danos reais ao sistema de arquivos (causados por um bug GFS2).

Na maioria dos casos, a melhor maneira de recuperar de um sistema de arquivo GFS2 retirado é reinicializar ou cercar o nó. O sistema de arquivo GFS2 retirado lhe dará a oportunidade de realocar os serviços para outro nó no cluster. Após a realocação dos serviços, você pode reinicializar o nó ou forçar uma cerca com este comando.

# pcs stonith fence node

O problema de consistência que causou a retirada pode impossibilitar a interrupção do serviço do sistema de arquivos, pois pode causar a suspensão do sistema.

Se o problema persistir após uma montagem posterior, você deve parar o serviço de sistema de arquivo para desmontar o sistema de arquivo de todos os nós no cluster, então execute uma verificação do sistema de arquivo com o comando fsck.gfs2 antes de reiniciar o serviço com o seguinte procedimento.

Você pode anular a função de retirada do GFS2 montando o sistema de arquivo com a opção -o errors=panic especificada no serviço de sistema de arquivo.

# pcs resource update mydata_fs “options=noatime,errors=panic”

Quando esta opção é especificada, quaisquer erros que normalmente causariam a retirada do sistema forçam um pânico no núcleo. Isto interrompe as comunicações do nó, o que faz com que o nó seja cercado. Isto é especialmente útil para clusters que são deixados sem vigilância por longos períodos de tempo sem monitoramento ou intervenção.

Internamente, a função de retirada do GFS2 funciona desligando o protocolo de travamento para garantir que todas as demais operações do sistema de arquivos resultem em erros de E/S. Como resultado, quando a retirada ocorre, é normal ver uma série de erros de E/S do dispositivo de mapeamento relatados nos logs do sistema.