2.7. 块分配

当 GFS2 文件系统接近满时，块分配程序在分配新块时会比较困难。因此，所有分配器分配的块往往被压缩到资源组的末尾，或者更有可能出现文件碎片的小块中。该文件的碎片可能会导致性能问题。另外，当 GFS2 文件系统接近满时，GFS2 块分配程序会通过多个资源组花费较长时间搜索，同时添加了锁定竞争，且不一定在该文件系统中有足够剩余空间。这也可能导致性能问题。

由于这些原因，建议您不要运行一个超过 85% 的文件系统，但这个数字会根据工作负载的不同而有所不同。

当为 GFS2 文件系统开发应用程序时，建议您在可能的情况下为每个节点分配它自己的文件。由于分布式锁管理器(DLM)的工作方式，如果所有文件都由一个节点分配，则会有更多锁竞争，而其他节点需要向这些文件添加块。

过去，术语"主锁"过去用来表示节点是锁请求的当前协调者，这些请求源自于本地或来集群中的远程节点。锁请求协调器的术语稍有误导，因为它实际上是一个资源（在 DLM 术语中），与哪个锁请求是排队的、授权的或拒绝的有关。在 DLM 中使用术语的意义上，应该视为 "对等中的第一个"，因为 DLM 是一个对等系统。

在 Linux 内核 DLM 实现中，在其上首先使用锁的节点会成为锁请求的协调者，在那之后没有变化。这是 Linux 内核 DLM 的实现详情，而不是一般的 DLM 属性。将来的更新可能会允许特定锁的锁请求的协调在节点间移动。

协调锁请求的位置对锁请求的启动者是透明的，但对请求延迟的影响除外。当前实现的一个结果是，如果初始工作负载有不平衡的情况（例如，在其他节点执行任何 I/O 命令前，一个节点扫描通过整个文件系统），与执行文件系统初始扫描的节点相比，可能会导致集群中其他节点的锁延迟更高。

与很多文件系统一样，GFS2 分配程序会尝试在同一文件中让块保持接近，以减少磁盘头的移动并提升性能。将块分配给文件的节点可能需要为新块使用和锁定同一资源组（除非该资源组中的所有块都被使用）。如果包含文件的资源组的锁请求协调者分配其数据块（让首先打开该文件的节点做所有新块的写操作会更快）时，文件系统将运行的更快。

如果文件预先分配，可以完全避免块分配，且该文件系统可以更有效地运行。GFS2 包含 fallocate(1) 系统调用，您可以使用它预分配数据块。