1.4. GFS2 格式化注意事项

要格式化 GFS2 文件系统以优化性能，您应该考虑这些建议。

文件系统大小：较小越好

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

注：虽然有可能使用 GFS2 大文件系统，但并不意味着推荐使用它们。GFS2 的一般原则是容量越小越好：最好使用 10 个 1TB 文件系统而不是使用一个 10TB 文件系统。

尽量保持 GFS2 文件系统较小的原因是：

另外，需要较少的资源组来保持更好的性能。

当然，如果您的 GFS2 文件系统太小，可能没有足够空间，这本身就会产生一定后果。在决定大小之前，您应该考虑您自己的具体用例。

块大小：默认(4K)块首选

mkfs.gfs2 命令会尝试根据设备拓扑估算最佳块大小。通常, 4K 块是首选块大小,因为 4K 是 Red Hat Enterprise Linux 的默认页面大小（内存）。与其他一些文件系统不同，GFS2 使用 4K 内核缓冲进行大多数操作。如果您的块大小是 4K，那么内核会在操作缓冲区时进行较少的工作。

建议您使用默认块大小，这样可获得最好的性能。只有在需要有效存储许多小文件时才可能需要使用不同的块大小。

日志大小：默认(128MB)通常是最佳设置

当您运行 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 尝试以两种方式缓解这个问题：

最糟糕的情况是，当存在所有节点创建文件的中央目录时，因为所有节点都会持续努力锁定同一资源组。