Is it possible to skip writing to cache for a GFS2 Filesystems?

Environment

• Red Hat Enterprise Linux Server 6, 7, 8, and 9
• High Availability Add On
• Resilient Storage Add Ons
• A Global Filesystem 2(gfs2)

Issue

While it is possible for processes writing to a gfs2 filesystem to skip caching or flush every write immediately, this is generally not advised:

The default behavior of writing to cache first and then flushing ( async ) is the recommend behavior. Red Hat does not advise skipping cache as this will severely reduce system performance and potentially reduce the lifetime of your storage devices.

Resolution

Mounting a gfs2 filesystem with the sync option will ensure that every new write is immediately flushed to disk. This solution is rarely needed though and not recommended. If it is required to use this option it is highly recommended to test the option thoroughly in a lower environment prior to placing this in production:

$ man mount
-----------------------------------------8<----------------------------------------- 
       sync
           All I/O to the filesystem should be done synchronously. In the case of media with a limited
           number of write cycles (e.g. some flash drives), sync may cause life-cycle shortening.

The above solution is rarely required and in most cases will cause a negative impact to system performance and possibly the storage as well. It is strongly advised to avoid using this option, and seek another solution where possible.

Possible Alternative Solutions:

• If there is a specific application need to skip cache and write directly to disk, then there may be available application specific configurations available which perform the direct I/O to disk, and this solution would be better then forcing everything to sync immediately.

  • Please check with your application provider for available options around this if required.
  • If this is an in house or custom application consider developing the application with direct I/O in mind.

• If the goal is to avoid large cache sizes, the be below documentation goes over why large cache can be either safe to ignore, and how you can exercise some control of the cache reclaim where needed as an alternate solution:

  • What is cache in "free -m" output and why is memory utilization high for cache?
  • How to control the size of page cache in RHEL?

• Another option if the concern is large page cache is to drop all page cache, but this additionally is generally not recommended:

  • Should the cache be dropped on a GFS2 file-system when a performance issue is occurring?

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.