How to mount a GFS2 filesystem when quorum is lost or from a host that is not a member of the cluster on RHEL?

Solution Verified - Updated 6 Aug 2024

Environment

Red Hat Enterprise Linux (RHEL) 6 or 7 with the Resilient Storage Add On
GFS2 file-system

Issue

I want to mount a GFS2 filesystem without starting the cluster services in Red Hat Enterprise Linux. How is this done?
How can I access GFS2 to perform backups from a san snapshot presented to a machine that is not part of the cluster?
How can I mount a clustered logical volume group on a machine that is not part of the cluster?
We are trying to mount clustered volume, GFS2 filesystem on one stand alone server for recovery purpose. But volume was not getting activated, so we had changed the locking_type = 0 in /etc/lvm/lvm.conf, then it's able to activate but getting following warning
```
  WARNING: Locking disabled. Be careful! This could corrupt your metadata.
```
Does this warning indicate any issue? Is it supported to mount GFS2 lvm volume with locking_type = 0?

Resolution

NOTE: Red Hat only provides support for gfs2 filesystems mounted under this procedure under limited conditions.

See: Support policies - Mounting conditions and procedures for gfs2 filesystems

WARNING: When a GFS2 filesystem is mounted with the lock_nolock option, it can no longer be mounted on multiple cluster nodes at the same time. Data corruption will occur if a GFS2 filesystem is mounted on more than 1 cluster node without lock_dlm locking protocol.

Mounting a `GFS2` file-system when a cluster has lost quorum

RHEL 8,9
How to activate shared volume group outside cluster control that utilizes lvmlockd shared activation

RHEL 6,7
This procedure is for when a cluster cannot achieve quorum for some reason and the GFS2 filesystem is on a clustered LVM (CLVM) volume which is required. It is advised that all cluster nodes shutdown their cluster services or at the very least stop clvmd on all cluster nodes.

Make sure that no hosts has the GFS2 filesystem mounted. If multiple host mount the same GFS2 filesystem at the same time then corruption will occur.

The vgchange command is not changing the locking type permanently, the locking type is only changed for the execution of the command.

In order to mount a GFS2 file-system with the lock_nolock protocol the locking type of the lvm volume will need to be temporarily changed. The reason is that for a lvm volume group to be active that has the c-bit or cluster bit enabled then the cluster has to have quorum. The vgchange command will temporarily activate the volume group that is currently disabled since the cluster does not have quorum and then the GFS2 filesystem is mounted.

# vgchange -ay vgTarget1 --config 'global { locking_type = 0 }'  
  WARNING: Locking disabled. Be careful! This could corrupt your metadata.
  1 logical volume(s) in volume group "vgTarget1" now active
# mount -t gfs2 -o lockproto=lock_nolock /dev/mapper/vgTarget1-lvol1 /mnt/gfs2lvol1-target1
# mount | grep lock_nolock
/dev/mapper/vgTarget1-lvol1 on /mnt/gfs2lvol1-target1 type gfs2 (rw,noatime,nodiratime,lockproto=lock_nolock,localflocks,localcaching)

To prepare to mount the GFS2 file-system in a cluster then the GFS2 will need to unmount the file-system and then deactivate the volume group which does not change the locking_type permanently:

# umount /mnt/gfs2lvol1-target1
# vgchange -an vgTarget1 --config 'global { locking_type = 0 }'

Mounting a `GFS2` file-system on a host that is not member of cluster for backup purposes

If you are planning to mount a `GFS2` filesystem on a host that does not have the cluster software installed, the only required package that needs to be installed is `gfs2-utils` which provides the command to mount the `GFS2` fileystem `mount.gfs2`.

A GFS2 filesystem is required to be on a clustered LVM (CLVM) volume. In order for a host that is not a member of the cluster to mount the GFS2 the lvm volume group will need to have its c-bit or cluster bit disabled.

Make sure that no hosts has the GFS2 filesystem mounted. If multiple host mount the same GFS2 filesystem at the same time then corruption will occur.

The vgchange command is not changing the locking type permanently, the locking type is only changed for the execution of the command.

Ensure that the volume group is not activated(there is no a bit) on any cluster nodes currently. It is recommended that the volume group is deactivated on all cluster nodes.

# vgchange -an vgTarget1
# lvs | grep vgTarget1
  lvol1   vgTarget1   -wi-------  9.00g

Once the lvm volume is deactivated then the c-bit or cluster bit needs to be removed, so that a host that is not member of the cluster that the GFS2 filesystem was created for can mount the filesystem.

# vgchange -cn vgTarget1 --config 'global { locking_type = 0 }'
  WARNING: Locking disabled. Be careful! This could corrupt your metadata.
  Volume group "vgTarget1" successfully changed

Then activate the volume group with the clustering bit disabled on the host that will be mounting the GFS2 file-system:

# vgchange -ay vgTarget1
  1 logical volume(s) in volume group "vgTarget1" now active
# mount -t gfs2 -o lockproto=lock_nolock /dev/mapper/vgTarget1-lvol1 /mnt/gfs2lvol1-target1
# mount | grep lock_nolock
/dev/mapper/vgTarget1-lvol1 on /mnt/gfs2lvol1-target1 type gfs2 (rw,relatime,lockproto=lock_nolock,localflocks,localcaching)

To prepare to mount the GFS2 file-system in a cluster then the GFS2 will need to be unmounted, then deactivate the volume group, then enable the c-bit or cluster bit on the volume group so that is a clustered (CLVM) volume.

# umount /mnt/gfs2lvol1-target1
# vgchange -an vgTarget1
# vgchange -cy vgTarget1 --config 'global { locking_type = 0 }'
  Volume group "vgTarget1" successfully changed
# vgchange -ay vgTarget1

Root Cause

It is useful to mount a GFS2 filesystem without clustered locking in situations where the cluster cannot reach quorum or the filesystem (or snapshot) needs to be mounted on a system outside of the cluster.
A GFS2 filesystems is only supported on clustered LVM (CLVM) volumes, and these cannot normally be activated outside of a quorate cluster.

SBR

Clusterha

Product(s)

Red Hat Enterprise Linux

Components

Category

Supportability

Tags

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.