2.9. Bloqueio de Nó GFS2
Para conseguir o melhor desempenho de um sistema de arquivos GFS2, é muito importante entender algumas teorias básicas de suas operações. Um sistema de arquivo de nó único é implementado junto com um cache, a razão do qual é eliminar a latência de acessos ao disco quando usar dados frequentemente requeridos. No Linux o cache de página (e históricamente o cache de buffer) fornece essa função de cache.
Com o GFS2, cada nó tem seu próprio cache de página que pode conter algumas porções de dados no disco. O GFS2 usa um mecanismo de bloqueio chamado glocks (pronunciado em inglês gee-locks) para manter a integridade do cache entre os nós. O subsistema glock fornece uma função de gerenciamento de cache que é implementada usando o gerenciador de bloqueio distribuído (DLM - distributed lock manager) como a camada de comunicação subjacente.
Os glocks fornecem proteção para o cache em uma base por nó, para que então haja um bloqueio por inode que é usado para controlar a camada de cache. Se esse glock é concedido para um modo compartilhado (DLM lock mode: PR) então os dados sob esse glock podem ser colocados em cache em um ou mais nós ao mesmo tempo, que então todos os nós possam ter acesso local aos dados.
Se o glock é concedido em modo exclusivo (DLM lock mode: EX) então somente um nó único pode fazer o cache dos dados sobre este glock. Este modo é usado por todas as operações que modificam os dados (tais como uma chamada de sistema
write).
Se um outro nó solicita um glock que não pode ser feito imediatamente, então o DLM envia uma mensagem ao nó ou nós que atualmente possuem os glocks bloqueando a nova solicitação para pedir aos nós para remover seus bloqueios. Removendo glocks pode ser (pelo padrão da maioria dos sistemas operacionais) um longo processo. Removendo um glock compartilhado requer somente que o cache seja invalidado, que é relativamente rápido e proporcional ao tamanho dos dados em cache.
Despejar (drop) um glock exclusivo requer uma liberação de log e escrever de volta quaisquer dados alterados no disco, seguido pela invalidação como por glock compartilhado.
A diferença entre um sistema de arquivos de nó único e o GFS2 então, é que um sistema de arquivos de nó único possui um cache único e o GFS2 possui um cache separado em cada nó. Em ambos os casos, a latência para acessar os dados em cache é como uma ordem similar de magnitude mas a latência para acessar dados sem cache é muito maior no GFS2 se outro nó tiver anteriormente feito o cache dos mesmos dados.
Nota
Devido à maneira na qual o cache do GFS2 é implementada, o melhor desempenho é obtido quando qualquer umas das situações seguintes acontecem:
- Um inode é usado em uma forma de leitura somente em todos os nós
- Um inode é escrito ou modificado a partir de um nó único somente.
Note que inserindo e removendo entradas de um diretório durante criação e exclusão de arquivos conta como escrita no diretório inode.
É possível quebrar esta regra desde que ela seja quebrada relativamente com infrequencia. Ignorando esta regra com frequencia resultará em uma severa penalidade no desempenho.
Se você usar
mmap() em um arquivo em GFS2 com mapeamento de escrita e leitura, mas somente leitura é feita, se contará apenas como leitura. No GFS entretanto, se conta como uma escrita, então o GFS2 é muito mais escalável com o mmap() de E/S.
Se você não ajudar o parâmetro
noatime mount, então leituras também resultarão em escritas para atualizar o arquivo timestamps. Nós recomendamos que todos usuários GFS2 deveriam ser montados com noatime ao menos que eles tenham um requerimento específico para o atime.
2.9.1. Problemas com o Bloqueio de Posix
Ao utilizar o bloqueio de Posix, você deve levar em consideração:
- Ao utilizar o Flocks, você irá gerar processamento mais rápido do que se utilizar os bloqueios de Posix.
- Programas que utilizam os bloqueios Posix no GFS2 devem evitar utilizar a função
GETLK, pois em um ambiente em cluster, o ID do processo pode ser para um nó diferente no cluster.
