2.7. 块分配
尽管只写数据的应用程序通常无法无需了解如何或在哪里分配块，但了解块分配如何工作可帮助您优化性能。
2.7.1. 在文件系统中保留空闲空间
当 GFS2 文件系统接近满时，块分配程序在分配新块时会比较困难。因此，所有分配器给出的块往往会被限制在资源组的末尾，或者更有可能将大量文件碎片处理。该文件的碎片可能会导致性能问题。另外，当 GFS2 文件系统接近满时，GFS2 块分配程序会通过多个资源组花费较长时间搜索，同时添加了锁定竞争，且不一定在该文件系统中有足够剩余空间。这也可能导致性能问题。
由于这些原因，建议您不要运行一个超过 85% 的文件系统，但这个数字会根据工作负载的不同而有所不同。
2.7.2. 在可能的情况下，每个节点分配自己的文件
当为 GFS2 文件系统开发应用程序时，建议您在可能的情况下为每个节点分配它自己的文件。由于分布式锁管理器(DLM)的工作方式，如果所有文件都被一个节点分配，则有更多锁定竞争，而其他节点则需要向这些文件添加块。
过去，术语"锁 master"过去用于表示当前锁定请求的协调者，这些请求源自于本地或来自集群中的远程节点。锁定请求协调器的术语稍具误导，因为它实际上是一个资源（在 DLM 术语中），与锁定请求是排队、拒绝或拒绝的关系。在 DLM 中使用术语的意义上，应该使用 "first among equals"，因为 DLM 是一个 peer-to-peer 系统。
在 Linux 内核 DLM 实现中，首先使用锁定的节点会成为锁定请求的协调器，此后它不会变化。这是 Linux 内核 DLM 的实现详情，而不是一般的 DLM 属性。将来的更新可能会允许协调特定锁定的锁定请求，以便在节点间移动。
协调锁定请求的位置对锁定请求的启动器是透明的，但对请求延迟的影响除外。当前实现的一个结果是，如果对初始工作负载造成不平衡的情况（例如，在其他人执行任何 I/O 命令前，通过整个文件系统进行一次节点扫描）可能会导致集群中其他节点的锁定延迟与执行文件系统初始扫描的节点进行比较。
与很多文件系统一样，GFS2 分配程序会尝试在同一文件中让块保持接近，以减少磁盘头的移动并提升性能。将块分配给文件的节点可能需要为新块使用和锁定同一资源组（除非该资源组中的所有块都被使用）。如果包含文件的资源组的锁定请求协调器分配其数据块（让首先打开该文件的节点更快）时，文件系统将更快运行。
2.7.3. 如果可能，预先分配
如果文件预先分配，可以完全避免块分配，且该文件系统可以更有效地运行。GFS2 包含 fallocate(1) 系统调用，您可以使用它预先分配数据块。
