Does Red Hat recommend exporting GFS or GFS2 with NFS or Samba in a RHEL Resilient Storage cluster, and how should I configure it if I do?

Solution Verified - Updated

Environment

  • RHEL 6 or 7 with the Resilient Storage Add On
  • Global File System 2 (gfs2)

Issue

  • Does Red Hat recommend and support using GFS or GFS2 for NFS exporting?
  • Do I require any special mount options when using GFS2 filesystem to serve NFS or Samba services?
  • Can I serve NFS in an active/active configuration on RHEL HA?
  • System panics when using clustered plocks on GFS2 to grant posix locks via NFS.
  • It is not possible to serve one GFS2 volume via NFS from multiple nodes at the same time if posix locks are being used for nfs locking.
  • The system panics on posix_lock_file
  • How do I share my GFS or GFS2 file systems over NFS?
  • The dlm_plock_callback must not appear in filesystem exported via NFS, follow resolution:
kernel: lockd: grant for unknown block
kernel: dlm: dlm_plock_callback: lock granted after lock</code>

Resolution

Support Policies and Requirements for exporting gfs2

See: Support policies - Exporting gfs2 contents via other protocols

Red Hat's Recommendations for NFS over gfs2 Deployments

Red Hat recommends using a single-host file system such as ext3, ext4, or xfs on a shared storage cluster in an active-passive / failover configuration, in order to take advantage of high availability provided by a cluster and the better performance offered by a non-clustered fs over a clustered fs like gfs2.

For data safety reasons, Red Hat's policies limit gfs2 to only being mounted by a single node if it is to be exported by NFS, and the filesystem can only be accessed through the export. Because gfs2's main benefit is typically that it serves as a multi-host clustered filesystem, this limitation eliminates most of the usefulness of that filesystem type over a single-host filesystem in an active/passive configuration.

When compared with typical single-host file systems like ext3, ext4, or xfs, clustered file systems gfs2 will typically perform worse, due to the nature of needing to share information across hosts and the overhead which comes along with that. The trade-off between this performance hit versus the ability to access data across hosts often can result in gfs2 being a better fit for certain use cases, but the limitations around exporting gfs2 with NFS generally preclude accessing exported data from multiple hosts. The end result is that an NFS-over-gfs2 deployment incurs the negative aspects of this file system type (lower performance) without getting any of the benefit (concurrent access across hosts). As such, single-node file systems are generally considered the better fit, as they're just as capable of being configured in active/passive NFS deployments and will typically achieve much better performance.

Red Hat's Recommendations for CIFS over gfs2 Deployments

Red Hat supports and recommends exporting gfs2 via CTDB for clustered, active / active exports.

Other environments that do not or can not use CTDB are subject to the same limitations described in the NFS recommendations above, and thus similarly single-host CIFS exports over gfs2 will typically have to incur the negative aspects of such a clustered file system (lower performance) without being able to realize any of the benefits (concurrent access across hosts).

References

SBR
Product(s)
Components
Category
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.