第 2 章 GFS2 配置及操作注意事项

GFS2 是基于 64 位架构，理论上可部署 8EB 的文件系统。但目前对 64 位架构硬件支持的最大 GFS2 文件系统为 100TB，对 32 位架构硬件支持的最大 GFS2 文件系统为 16TB。

注：即使 GFS2 超大文件系统是可能的，但并不意味着建议您采用。一般来说 GFS2 是越小越好：十个 1TB 大小的文件系统要好过一个 10TB 大小的文件系统。

保持较小的 GFS2 文件系统有以下几个原因：

另外，需要维护的资源组越少，意味着性能更佳。

当然，如果 GFS2 文件系统太小，则可能会造成空间溢出，也会造成一定影响。请在决定文件系统大小前考虑自身使用情况。

从 Red Hat Enterprise Linux 6 开始，mkfs.gfs2 命令会尝试根据设备拓扑估算最佳块大小。通常，4K 块是首选块大小，因为 4K 是 Linux 的默认页大小（内存）。与其他文件系统不同，GFS2 使用 4K 内核缓存执行其大多数操作。如果您的块大小为 4K，则内核操作缓存的动作就少。

建议您使用可形成最高性能的默认块大小。

GFS2 要求集群中每个需要挂载该文件系统的节点都有一个日志。例如：如果您有一个有 16 个节点的集群，但只需要在其中的 2 个节点中挂载该文件系统，那么您就只需要两个日志。如果您需要挂载第三个节点，您总是可以使用gfs2_jadd 命令添加日志。在 GFS2 中您可以随时添加日志。

在运行 mkfs.gfs2 命令生成 GFS2 文件系统时要指定日志的大小。如果没有指定大小，则默认为 128MB，这对大多数应用程序都是最佳选择。

有些系统管理员可能认为 128MB 太大，并尝试将该日志大小减小到 8MB，或者保守地保留为 32MB。虽然可能正常工作，但仍会严重影响性能。与许多日志文件系统一样，每次 GFS2 写入元数据时，都会在元数据到位前提交到日志中。这样是为保证如果系统崩溃或者断电，则可恢复所有元数据，因为挂载时会自动使用日志替换。但如果使用 8MB 的日志，则无法记录太多的文件系统活动，同时当日志写满后，性能就会下降，因为 GFS2 必须等待写入存储。

一般推荐使用默认日志大小，即 128MB。如果文件系统太小（比如说 5GB），128MB 的日志就不太合适。如果文件系统较大，且有充分的空间，使用 256MB 日志可能会改进性能。

使用 mkfs.gfs2 命令创建 GFS2 文件系统时，它将存储分成统一的片段，即资源组。它尝试估算最佳资源组大小（范围在32MB 到 2GB 之间）。您可以使用 mkfs.gfs2 命令的 -r 选项覆盖默认值。

最佳资源组大小取决于如何使用该文件系统。请注意该文件会有多满，或者是否会被严重分割成碎片。

请尝试不同大小的资源组查看最佳性能。最好是在产品中部署 GFS2 前在测试集群中进行试验。

如果文件系统有太多资源组（每个都太小），则块分配会浪费太多时间搜索数以万计（或者十万计）的资源组才能找到空余的块。您的系统越满，则需要搜索的资源组越多，且它们都需要集群范围锁。这就会降低性能。

如果您的文件系统只有很少几个资源组（每个都很大），块分配可能会更频繁地访问同一资源组锁，这样也会影响性能。例如：如果您有一个 10GB 文件系统，分成 5 个 2GB 的资源组，您集群中的节点会比将同一文件系统分成 320 个资源组，每个 32MB 更频繁地访问那 5 个资源组。尤其是在文件系统快满的时候更为严重，因为每个块分配可能都必须在找到可用块之前查看几个资源组。GFS2 尝试从两个方面解决这个问题：

最糟糕的情况是在有中央目录时，则所有节点都在该目录中创建文件，因为所有节点将不断尝试锁定同一资源组。