Support Policies for RHEL Resilient Storage - Mounting conditions and procedures for gfs2 filesystems
Contents
Overview
Applicable Environments
- Red Hat Enterprise Linux (RHEL) with the Resilient Storage Add-On
Useful References and Guides
Introduction
This policy guide describes Red Hat's policies around the mounting of gfs2 filesystems. Users of gfs2 should adhere to these policies in order to be eligible for support from Red Hat with the appropriate product support subscriptions.
Policies
Mounting requirements: Any cluster node that is mounting or has mounted a gfs2 filesystems is required to have gfs2-utils installed in order for a withdraw to complete successfully . For more information then see the following: What is a GFS2 withdrawal in a RHEL Resilient Storage cluster?
gfs2 filesystems can only be mounted within a single cluster: Any single gfs2 filesystem can only be mounted within a single cluster at a time. If a gfs2 filesystem is mounted anywhere, that filesystem can only be simultaneously mounted by another member of the same cluster.
A single gfs2 filesystem cannot be mounted by nodes from different clusters, or by a node in a cluster and a non-cluster member.
gfs2 mounting procedures: Red Hat makes available several methods to mount gfs2 filesystems, but only supports the following methods of activating a gfs2 filesystem on a host. Other methods may not receive assistance from Red Hat:
- RHEL 9, 8, 7, or 6: Mounting via the
mount -t gfs2ormount.gfs2command, either with the filesystem configured in/etc/fstabor providing the mount parameters directly to the command. - RHEL 9, 8, 7, or 6: Mounting via a
pacemaker-managedocf:heartbeat:Filesystemresource withfstype=gfs2 - RHEL 6: Mounting via an
rgmanager-managedclusterfsresource withfstype=gfs2 - RHEL 6: Mounting by starting the
gfs2init service with the filesystem configured in/etc/fstab
Note: With RHEL 7, 8, or 9 Red Hat recommends mounting gfs2 via a Filesystem resource in the pacemaker cluster, as detailed here. When mounting gfs2 via a managed cluster resource, that filesystem should not be defined in /etc/fstab.
Lock protocols: gfs2 makes available a few different lock protocols that can be defined in the filesystems superblock or specified at mount time via an option or flag. Red Hat only provides support for two such protocols in RHEL Resilient Storage deployments, each with its own conditions:
-
lock_dlm: Agfs2filesystem must be mounted with this protocol if it is to be mounted across several hosts simultaneously. Each host mounting agfs2filesystem with this protocol must be an active, quorate member of a RHEL High Availability cluster and must be runningdlm_controld- started by acontroldcluster-managed resource in a RHEL 8 or 7 cluster or by thecmaninit service in RHEL 6. -
lock_nolock- This protocol allows agfs2filesystem to be mounted on a host without it being an active, quorate member of a cluster, or without it runningdlm_controld. However, only a single host can mount agfs2file system at a time if this protocol is in use. Red Hat will only provide support or assistance withgfs2filesystems that are usinglock_nolockunder the following conditions:- Backups: Red Hat can assist with usage of
gfs2withlock_nolockas a temporary protocol for the purpose of backing up the filesystem's contents. - Emergency recovery: Red Hat can assist with usage of
gfs2withlock_nolockif it is deployed as a temporary measure to gain access to a filesystem under emergency conditions where the cluster ordlm_controldservice is unable to facilitate mounting withlock_dlm. For continued assistance from Red Hat with alock_nolockgfs2mount, there must be a reasonable expectation that filesystem will be returned to alock_dlmconfiguration once the emergency has passed and problematic conditions can be resolved.
- Backups: Red Hat can assist with usage of
Mounting gfs2 without an active, quorate cluster: gfs2 can only be mounted outside of an active, functioning cluster by using the lock_nolock protocol. See the above Lock protocols policy for conditions applicable to mounting a gfs2 filesystem with this protocol without having a functional cluster.
- For a procedure to mount
gfs2without an active, quorate cluster, see: How to mount a GFS2 filesystem when quorum is lost or from a host that is not a member of the cluster on RHEL?
gfs2 localflocks mount option: gfs2 provides a localflocks option at mount time that influences it to allow the kernel VFS layer to do all flock and fcntl (POSIX) file locking, instead of handling these through gfs2's clustered-locking schemes. Red Hat only provides support for a gfs2 filesystem that uses this option if it is only being mounted on a single node at a time. Any usage of localflocks in which the filesystem gets mounted by multiple nodes simultaneously disqualifies that filesystem from receiving assistance from Red Hat.
gfs2 with SELinux: Special policies apply to usage of gfs2 with SELinux.
Mounting gfs2 on only some nodes: gfs2 does not require that all members of the cluster mount the filesystem. It can be mounted on a single node if desired, some subset of the total cluster, or all nodes.
Comments