8.3. Glocks

Para entender GFS2, el concepto más importante que hay que entender, y el que lo diferencia de otros sistemas de archivos, es el concepto de glocks. En términos del código fuente, un glock es una estructura de datos que reúne el DLM y la caché en una sola máquina de estado. Cada glock tiene una relación 1:1 con un único bloqueo del DLM, y proporciona el almacenamiento en caché de ese estado de bloqueo para que las operaciones repetitivas realizadas desde un único nodo del sistema de archivos no tengan que llamar repetidamente al DLM, y así ayudan a evitar el tráfico de red innecesario. Existen dos grandes categorías de glocks, los que almacenan en caché los metadatos y los que no. Los glocks de inodo y los glocks de grupo de recursos almacenan en caché los metadatos, los otros tipos de glocks no almacenan en caché los metadatos. El inode glock también participa en el almacenamiento en caché de los datos además de los metadatos y tiene la lógica más compleja de todos los glocks.

Los glocks permanecen en memoria hasta que se desbloquean (a petición de otro nodo o a petición de la VM) y no hay usuarios locales. En ese momento se eliminan de la tabla hash de glock y se liberan. Cuando se crea un glock, el bloqueo DLM no se asocia con el glock inmediatamente. El bloqueo DLM se asocia con el glock en la primera petición al DLM, y si esta petición tiene éxito entonces la bandera 'I' (inicial) se establecerá en el glock. Tabla 8.4, “Banderas Glock” muestra los significados de las diferentes banderas del glock. Una vez que el DLM ha sido asociado con el glock, el bloqueo del DLM siempre permanecerá al menos en el modo de bloqueo NL (Nulo) hasta que el glock sea liberado. Una degradación del bloqueo DLM de NL a desbloqueado es siempre la última operación en la vida de un glock.

Cada glock puede tener un número de "holders" asociados, cada uno de los cuales representa una solicitud de bloqueo de las capas superiores. Las llamadas del sistema relacionadas con GFS2 ponen en cola y decaen los titulares del glock para proteger la sección crítica del código.

La máquina de estado glock se basa en una cola de trabajo. Por razones de rendimiento, los tasklets serían preferibles; sin embargo, en la implementación actual necesitamos enviar E/S desde ese contexto, lo que prohíbe su uso.

Tabla 8.2, “Modos y tipos de datos de Glock” muestra qué estado puede ser almacenado en caché bajo cada uno de los modos de glock y si ese estado almacenado en caché puede estar sucio. Esto se aplica tanto a los bloqueos de inodos como a los de grupos de recursos, aunque no hay ningún componente de datos para los bloqueos de grupos de recursos, sólo metadatos.