Is there more information on how GFS2 cache works on RHEL 6 and RHEL 7?

Updated 18 Feb 2015

How is GFS2 lock caching managed?

The best description is explained in the following article on [GFS2 cache]( https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Global_File_System_2/index.html#s1-ov-lockbounce).

How can the amount of cached GFS2 locks be kept small?

The cache can be tuned and the following explains how: [How to control the size of page cache in RHEL? ](/solutions/32769)

Note that the page cache is very important for the performance of GFS2. In most configurations no tuning is required. Tuning incorrectly could result in bad performance and following article has more information on GFS2 and tuning.

Is the amount of cached GFS2 locks related to system memory size?

Yes GFS2 cache size is related to memory. There is no way to directly change the cache size. See the following article: [How to control the size of page cache in RHEL?](/solutions/32769).

Are deleted files removed from the cache?

Everything is cached until the kernel decides to clean it up as described in the following article: [How does GFS2 know when to deallocate a file?](/articles/56250)

The glocks should be removed from cache when files are deleted, unless:

They're held open by another process, a NO_CACHE option(cannot remember the version) was added to the glock so that when the last process closes the file, its i_open glock should be removed from the active glocks when the file is actually deleted by the last process to close it. The glock should be removed from cache at that point.
The dinode is re-used by a different file after it's been deleted, in which case there is likely to result in a performance problem and possible bug.

When unmounting a GFS2 filesystem the system can be very slow and shows `dlm_recv`, `dlm_recoverd`, etc. using 100% cpu.

True, when an unmount occurs then all of that filesystem's cache on the respective node gets invalidated/cleared. This can take a long time and cause the unmount operation to appear to hang. This could be normal for your GFS2 filesystem. GFS2 is designed to be mounted at all times on all cluster nodes, the unmounting of GFS2 should not happen often because it can be an intense operation in some configurations.

This is a RHEL 5 issue, but provides description of what can occur when a massive page cache drop occurs: GFS2 filesystems intermittently hang and glock_workqueue processes use 100% CPU in RHEL 5.