SELinux 和 GFS2

GFS2 支持扩展属性（xattrs）并且可以像 XFS 和 ext4 一样存储 Security Enhanced Linux (SELinux) 使用的文件标签。
然而，在 GFS2 文件系统上对 SELinux 文件标签的更新目前与集群不一致，因此将 SELinux 与 GFS2 一起使用是很复杂的。

这意味着如果一个节点更改了 GFS2 文件系统上文件的 SELinux 上下文，则挂载该文件系统的其他集群节点可能会无限期地继续使用该文件上的旧上下文。
这个问题解决起来有些棘手，目前正在 bugzilla.redhat.com 上将该问题作为错误 #437984 进行跟踪。

由于这个问题，最好不要将 SELinux 标签写入 GFS2 文件系统上的单个文件。
由于 GFS2 存储文件 xattrs 的方式，更新这些标签可能会导致特定于 GFS2 的性能损失。
对于涉及许多小文件的工作负载，这可能最为明显。
在仍然使用 SELinux 时可能有助于解决此问题的一种方法是利用挂载选项 context= 在挂载时将该 GFS2 文件系统上的所有文件的上下文设置为特定值。
这将避免 xattr 查找和写入。
或者，可以采取其他步骤来确保文件系统上的文件标签在由多个节点挂载时不会更改。

如果文件上的 SELinux 标签没有改变，那么在强制模式下的 SELinux 将在 GFS2 文件系统中正常运行，而红帽会在 SELinux 强制开启的情况下测试 GFS2 文件系统和整个集群堆栈。

注意：红帽建议在集群部署中使用 GFS2 的客户联系红帽进行架构审查，以确保计划的集群配置是可支持的。
完全支持 GFS2，但它并不适合所有环境和工作负载。

全局文件系统 2 (GFS2)

全局文件系统 2 (GFS2) 是一个直接与内核 VFS 层接口的集群文件系统。
这意味着多个集群节点可以同时挂载和使用同一个文件系统，同时仍然提供完整的常规文件系统，包括支持 POSIX ACL、扩展属性和配额等功能。

为了实现这一点，每个访问 GFS2 文件系统的节点都使用 Corosync 和 Pacemaker 提供的集群基础设施来提供防护和锁定等服务。
挂载 GFS2 文件系统的每个集群节点将使用单独的日志。
如果一个节点出现故障，集群中的其他节点之一将在故障节点被隔离后重播故障节点的日志。
为防止访问文件系统时两个节点之间出现争用情况，GFS2 使用分布式锁管理器 (DLM) 来协调文件和目录上的锁。

注意：Red Hat 不支持将 GFS2 用作单节点文件系统，或者超过 16 个节点的集群部署。
如果单个节点需要高性能、可扩展的服务器文件系统，红帽建议使用默认的 XFS 文件系统，或者作为替代，ext4.

在纯 64 位环境中运行时，GFS2 文件系统理论上可以扩展到 8 EiB。
但是，Red Hat 当前支持的最大 GFS2 文件系统大小为 100 TiB 。
对于大多数部署，拥有多个较小的文件系统比单个大文件系统更有意义。
在较大的文件系统上，运行 fsck.gfs2 命令将花费更长的时间，并使用更多的内存。
从备份完全恢复文件系统也需要更长的时间。

注意：Red Hat 目前仅支持在 CLVM 集群逻辑卷上创建的 GFS2 文件系统。

Red Hat 提供 GFS2 文件系统和 CLVM 作为 Red Hat Enterprise Linux Server 弹性存储添加组件的一部分。
弹性存储添加组件包括作为订阅一部分的高可用性添加组件。