To understand GFS2, the most important concept to understand, and the one which sets it aside from other file systems, is the concept of glocks. In terms of the source code, a glock is a data structure that brings together the DLM and caching into a single state machine. Each glock has a 1:1 relationship with a single DLM lock, and provides caching for that lock state so that repetitive operations carried out from a single node of the file system do not have to repeatedly call the DLM, and thus they help avoid unnecessary network traffic. There are two broad categories of glocks, those which cache metadata and those which do not. The inode glocks and the resource group glocks both cache metadata, other types of glocks do not cache metadata. The inode glock is also involved in the caching of data in addition to metadata and has the most complex logic of all glocks.
Table C.1. Glock Modes and DLM Lock Modes
|Glock mode||DLM lock mode||Notes|
| UN || IV/NL || Unlocked (no DLM lock associated with glock or NL lock depending on I flag) |
| SH || PR || Shared (protected read) lock |
| EX || EX || Exclusive lock |
| DF || CW || Deferred (concurrent write) used for Direct I/O and file system freeze |
Glocks remain in memory until either they are unlocked (at the request of another node or at the request of the VM) and there are no local users. At that point they are removed from the glock hash table and freed. When a glock is created, the DLM lock is not associated with the glock immediately. The DLM lock becomes associated with the glock upon the first request to the DLM, and if this request is successful then the 'I' (initial) flag will be set on the glock. Table C.4, “Glock flags”
shows the meanings of the different glock flags. Once the DLM has been associated with the glock, the DLM lock will always remain at least at NL (Null) lock mode until the glock is to be freed. A demotion of the DLM lock from NL to unlocked is always the last operation in the life of a glock.
This particular aspect of DLM lock behavior has changed since Red Hat Enterprise Linux 5, which does sometimes unlock the DLM locks attached to glocks completely, and thus Red Hat Enterprise Linux 5 has a different mechanism to ensure that LVBs (lock value blocks) are preserved where required. The new scheme that Red Hat Enterprise Linux 6 uses was made possible due to the merging of the
lock_dlm lock module (not to be confused with the DLM itself) into GFS2.
Each glock can have a number of "holders" associated with it, each of which represents one lock request from the higher layers. System calls relating to GFS2 queue and dequeue holders from the glock to protect the critical section of code.
The glock state machine is based on a workqueue. For performance reasons, tasklets would be preferable; however, in the current implementation we need to submit I/O from that context which prohibits their use.
Workqueues have their own tracepoints which can be used in combination with the GFS2 tracepoints if desired
Table C.2, “Glock Modes and Data Types”
shows what state may be cached under each of the glock modes and whether that cached state may be dirty. This applies to both inode and resource group locks, although there is no data component for the resource group locks, only metadata.
Table C.2. Glock Modes and Data Types
|Glock mode||Cache Data||Cache Metadata||Dirty Data||Dirty Metadata|
| UN || No || No || No || No |
| SH || Yes || Yes || No || No |
| DF || No || Yes || No || No |
| EX || Yes || Yes || Yes || Yes |