Menu Close

1.4. GFS2 格式化注意事项

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

重要

请确定您部署的 Red Hat High Availability Add-On红 满足您的需要并可支持。部署前请咨询权威红帽代表确认您的配置。

文件系统大小:较小越好

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

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

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

  • 备份每个文件系统需要较少的时间。
  • 如果您需要使用 fsck.gfs2 命令检查文件系统,则需要较少的时间。
  • 如果您需要使用 fsck.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 尝试以两种方式缓解这个问题:

  • 首先,当资源组完全满时,它会记住,并尝试避免在将来分配时检查它们,直到块从中释放。如果您从不删除文件,则这个问题并不严重。但是,如果您的应用程序正在持续删除块并在文件系统中分配最多完全的新块,则竞争会非常高,并且会对性能有严重影响。
  • 其次,当在现有文件中添加新块时,GFS2 将尝试将新块分组到与该文件相同的资源组群中。这么做的目的是为了提高性能:在旋转磁盘中,如果存储在物理位置上接近,则操作需要较少的时间。

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