C.3. Glocks

Para entender GFS2, o conceito mais importante a entender, e que o distingue de outros sistemas de arquivos, é o conceito de Glocks. Em termos de código-fonte, uma glock é uma estrutura de dados que reúne a DLM e cache em uma máquina de estado único. Cada glock tem uma relação de 1:1 com um único bloqueio DLM, e fornece armazenamento em cache para aquele estado de bloqueio, assim as operações repetitivas realizadas a partir de um único nó do sistema de arquivos não precisam chamar repetidamente a DLM, e portanto ajudam a evitar tráfego de rede desnecessário. Existem duas amplas categorias dos Glocks, aqueles que realizam cache de metadados e aquelas que não. Os glocks inode e o grupo de recursos Glocks, ambos que realizam cache de metadados, outros tipos de Glock não realizam o cache de metadados. O inodo Glock também está envolvido na realização de cache de dados, além de metadados e tem a lógica mais complexa de todos os Glocks.

Glocks permanecem na memória até que eles sejam desbloqueados (a pedido de outro nó, ou a pedido da VM) e não há usuários locais. Nesse ponto, eles são removidos da tabela hash glock e libertados. Quando um glock é criado, o bloqueio DLM não é associado com a Glock imediatamente. O bloqueio DLM torna-se associado com a glock no primeiro pedido para o DLM, e se esse pedido for bem sucedido, então a bandeira 'I' (inicial) será definida no glock. Tabela C.4, “Sinalizadores Glock” mostra os significados das bandeiras diferentes do glock. Depois da DLM ter sido associada ao Glock, o bloqueio DLM permanecerá sempre em pelo menos no modo de bloqueio NL (Nulo) até que o Glock seja libertado. Um rebaixamento de bloqueio DLM a partir de NL para desbloqueado é sempre a última operação na vida de um glock.

Cada Glock pode ter um número de "holders" associados, cada um dos quais representa uma solicitação de bloqueio a partir das camadas mais altas. Chamadas do sistema relacionadas com a fila do GFS2 e holders que retiram da fila do glock para proteger a seção crítica do código.

A máquina de estado do glock é baseada em fila de trabalho. Por razões de desempenho, tasklets deve ter preferência. No entanto, na atual implementação precisamos submeter I/O daquele contexto que proibe seu uso.

Tabela C.2, “Modos de Glock e Tipos de Dados” mostra qual o estado que pode ser armazenado em cada um dos modos de glock e se esse estado em cache pode estar sujo. Isso se aplica tanto ao inode quanto para bloqueios de grupos de recursos, embora não haja nenhum componente de dados para as travas do grupo de recursos, somente os metadados.