第 7 章 诊断并修正 GFS2 文件系统的问题
以下流程描述了一些常见的 GFS2 问题，并提供了有关如何解决它们的信息。
7.1. GFS2 文件系统对节点不可用（GFS2 撤回功能）
GFS2 withdraw 功能是 GFS2 文件系统的数据完整性功能，可防止因为硬件或者内核软件造成潜在的文件系统损坏。如果 GFS2 内核模块在任何指定集群节点中使用 GFS2 文件系统时检测到不一致的情况，它会从该文件系统中撤回（withdraw），并使它在相应的节点上不可用，直到卸载并重新挂载该节点（或者被探测到有问题的机器被重启）。所有其他挂载的 GFS2 文件系统在那个节点中仍能完全正常工作。（GFS2 撤回功能没有内核的 panic 严重，内核 panic 会导致该节点被隔离。）
可能导致 GFS2 撤回的主要原因：
- 内节点一致性错误
- 资源组一致性错误
- 日志一致性错误
- Magic number 元数据一致性错误
- 元数据类型一致性错误
因为不一致性导致 GFS2 撤回的一个示例是，文件内节点的不正确的块计数。当 GFS2 删除一个文件时，它会系统性地删除该文件引用的所有数据和元数据块。在完成后，它会检查内节点的块计数。如果块计数不是 1（1 代表所有剩下的都是磁盘内节点），这表示文件系统不一致，因为内节点的块数量与该文件使用的实际块不匹配。在很多情况下，问题可能是由硬件故障造成的（内存、主板、HBA、磁盘驱动器、电缆等出问题）。也可能是由内核的程序漏洞（另一个内核模块意外覆盖 GFS2 内存）或者实际文件系统损坏（由 GFS2 错误导致）造成的。
在大多数情况下，从 GFS2 文件系统中恢复的最佳方法是重新引导或者隔离该节点。撤回的 GFS2 文件系统将给您一个将服务重新定位到集群的另一个节点的机会。重新定位服务后，您可以重新引导节点或使用这个命令强制进行隔离。
pcs stonith fence node
不要尝试使用 umount 和 mount 命令手动卸载和重新挂载文件系统。您必须使用 pcs 命令，否则 Pacemaker 会检测到文件系统服务已消失，并隔离节点。
导致撤回的一致性问题可能会导致无法停止文件系统服务，因为它可能导致系统挂起。
如果重新挂载后问题仍然存在，您应该停止该文件系统服务以从集群中的所有节点卸载文件系统，然后在按照以下流程重启服务前使用 fsck.gfs2 命令执行文件系统检查。
- 重新引导受影响的节点。
在 Pacemaker 中禁用非克隆文件系统服务，以从集群中的每个节点卸载文件系统。
# pcs resource disable --wait=100 mydata_fs从集群的一个节点对文件系统设备运行
fsck.gfs2命令，来检查和修复文件系统损坏。# fsck.gfs2 -y /dev/vg_mydata/mydata > /tmp/fsck.out通过重新启用文件系统服务从所有节点中重新挂载 GFS2 文件系统：
# pcs resource enable --wait=100 mydata_fs
您可以使用文件系统服务中指定的 -o error=panic 选项挂载文件系统来覆盖 GFS2 撤回功能。
# pcs resource update mydata_fs “options=noatime,errors=panic”当指定这个选项时，所有会导致系统撤回的错误都是强制造成一个内核 panic。这样可停止节点的通讯，从而可以隔离该节点。这对于长时间无人值守、而无需监控或干预的集群特别有用。
GFS2 撤回的内部工作原理是，断开锁定协议以确保以后所有的文件系统操作都会出现 I/O 错误。因此，当发生撤回时，通常会在系统日志中看到来自设备映射器的 I/O 错误。
