4.14. A Função de Retirada do GFS2

A função withdraw (retirada) do GFS2 é um recurso de integridade de dados dos sistemas de arquivos GFS2 em um cluster. Se o modulo do kernel GFS2 detecta uma inconsistência em um sistema de arquivos GFS2 depois de uma operação de E/S, o sistema de arquivos se torna indisponível ao cluster. A operação de E/S pára e o sistema aguarda por mais operações de E/S para dar como erro, prevenindo mais danos. Quando isso ocorre, você pode parar quaisquer outros serviços ou aplicações manualmente, depois do qual você pode reinicializar e remontar o sistema de arquivos GFS2 para re-executar os diários. Se o problema repetir, você pode desmontar o sistema de arquivos de todos os nós no cluster e realizar uma recuperação do sistema de arquivos com o comando fsck.gfs2. A retirada da função GFS é menos severa que um pânico do kernel, que causaria um outro nó fazer um fence neste nó.

Se seu sistema estiver configurado com o script de inicialização gfs2 ativado e o sistema de arquivos GFS2 estiver incluído no arquivo /etc/fstab, o sistema de arquivos GFS2 será remontado quando você reinicializar. Se o sistema de arquivos GFS2 foi retirado porque percebeu uma corrupção do sistema de arquivos, é recomendado que você execute o comando fsck.gfs2 antes de remontar o sistema de arquivos. Neste caso, para previnir seu sistema de arquivos de remontar na inicialização, você pode seguir o seguinte procedimento:

Um exemplo de uma inconsistência que submeteria uma remoção do GFS2 é uma contagem de blocos incorreta. Quando o kernel GFS deleta um arquivo de um sistema de arquivos, ele semânticamente remove todos os dados e blocos de metadados associados com esse arquivo. Quando isso é feito, ele checa a contagem de blocos. Se a contagem de blocos não é "um" (significando que tudo que restou é o próprio inode de disco), que indica que uma inconsistência do sistema de arquivos já que a contagem de bloco não correspondeu à lista de blocos encontradas.

Você pode sobrescrever a função de retirada do GFS2 montado o sistema de arquivos com a opção -o errors=panic especificada. Quando esta opção é especificada, quaisquer erros que normalmente causariam a retirada do sistema faz o sistema entrar em pânico. Isto pára as comunicações de cluster dos nós, que faz o nó entrar em fence.

Internamente, a maneira que a função de retirada do GFS2 trabalha é fazer o kernel enviar uma mensagem ao daemon gfs_controld requerendo a retirada. O daemon gfs_controld roda o programa dmsetup para colocar o alvo do erro do mapeador de dispositivos sob o sistema de arquivos prevenindo acesso ao dispositivo de bloco. Ele então diz ao kernel que a operação foi completada. Esta é a razão para o requerimento de suporte do GFS2 para sempre usar um dispositivo CLVM sob GFS2, já que de outra maneira não é possível inserir um alvo de mapeador de dispositivo.

O propósito do alvo de erro do mapeador de dispositivo é garantir que todas as operações de E/S futuras resultarão em um erro de E/S que permitirão ao sistema de arquivos ser desmontado de uma maneira ordenada. Como um resultado, quando a retirada ocorre, é normal ver erros de E/S do dispositivo mapeador relatados nos sistemas de logs.

Ocasionalmente, a retirada pode falhar se não for possível para o programa dmsetup inserir os alvos de erro conforme requeridos. Isto pode ocorrer se há uma falta de memória no ponto de retirada e mais memória não pode ser recuperada devido ao problema que desencadeou a retirada em primeiro lugar.

Uma retirada nem sempre significa que há um erro no GFS2. As vezes a função de retirada pode ser iniciada por erros no dispositivo de E/S relacionado ao bloco de dispositivo subjacente. É altamente recomendável verificar os logs para ver se esse é o motivo se uma retirada ocorrer.