Linux XFS 项目配额怎么限制目录用量：project ID、xfs_quota 与超限验证

一台 XFS 服务器上，多个团队共用同一个挂载点，最容易失控的是某个目录树持续写入，把整块盘的余量吃光。按目录限制用量时，XFS 的项目配额比给用户逐个设 quota 更贴合这个边界：用 project ID 绑定目录树，再给项目设置 block 或 inode 限额。

真正决定配额是否生效的是三件事：XFS 挂载时启用了项目配额、目录树被稳定映射到 project ID、xfs_quota 的 report 能看到该项目并在写入后反映使用量。

项目配额解决的是哪一种目录压力

用户配额适合“某个 UID 最多用多少”，组配额适合“某个 GID 最多用多少”。项目配额的边界则是目录树：例如 /srv/build-cache 下的构建缓存由多个服务账号写入，但业务上希望它整体不超过 80 GiB。

这里的“项目”不是 Linux 用户组，也不是一个独立分区。XFS 会把项目 ID 记录到目录树中的 inode，再按这个 ID 汇总块和 inode 使用量。目录归属变化时，配额边界仍然跟着项目走。

先确认文件系统具备项目配额条件

先找到目标目录所在的 XFS 挂载点，不要直接对路径猜测：

findmnt -T /srv/build-cache -o TARGET,SOURCE,FSTYPE,OPTIONS
df -Th /srv/build-cache

输出中的文件系统类型应为 xfs。如果挂载选项没有项目配额相关选项，先按发行版文档准备维护窗口并确认内核、xfsprogs 支持情况；不要在生产盘上直接反复 remount 试错。内核文档把 XFS 配额细节指向 xfs_quota，实际命令以本机版本的手册为准。

用 project ID 把目录树固定下来

假设目录是 /srv/build-cache，给它分配项目名 buildcache 和 ID 1201。先编辑两个映射文件：

# /etc/projects
1201:/srv/build-cache

# /etc/projid
buildcache:1201

保存后，使用扩展模式让 xfs_quota 应用项目属性：

xfs_quota -x -c 'project -s buildcache' /srv/build-cache
xfs_quota -x -c 'state' /srv/build-cache

此时检查点不是“命令没有报错”，而是项目设置已应用到目标目录树。目录里已有文件时，应用过程会递归处理；目录层级较大要先估算执行时间，并在业务低峰操作。

再设置 block 和 inode 的软硬边界

项目配额常见的两个维度是块和 inode。下面给出一个实验值：软限制 70 GiB、硬限制 80 GiB，同时限制 inode 数量为 2,000,000：

xfs_quota -x -c 'limit -p bsoft=70g bhard=80g isoft=1800000 ihard=2000000 buildcache' /srv/build-cache
xfs_quota -x -c 'report -p -h' /srv/build-cache

软限制允许一定的宽限期策略，硬限制是更直接的写入上限。容量配额和 inode 配额是两个独立维度：小文件很多时，磁盘空间尚未到 80 GiB，也可能先撞上 inode 硬限制。

用 report 和受控写入验证是否真的拦截

先保存配置前的报告，再执行一次小规模写入，前后各看一次项目报告：

xfs_quota -x -c 'report -p -h' /srv/build-cache
dd if=/dev/zero of=/srv/build-cache/quota-test.bin bs=1M count=16 conv=fsync
xfs_quota -x -c 'report -p -h' /srv/build-cache
rm -f /srv/build-cache/quota-test.bin

报告中的 project 1201 或名称 buildcache 应出现使用量变化。要验证硬限制，必须在测试目录和维护窗口里写入足以接近上限的数据，并记录命令返回值及应用日志；不要为了“看到报错”把生产盘写满。

三个容易让配额看起来失效的反例

只改了 /etc/projid

名称映射让输出更易读，但它本身不会把目录加入项目。缺少 /etc/projects 或没有执行 project -s，report 里就可能没有预期项目。

把项目配额当成用户配额

同一目录树由多个 UID 写入时，逐个设置用户限额会让总量边界变得难以推断。项目配额应当作为目录树的总账，用户或组配额再按需要叠加。

只看 df，不看 xfs_quota report

df 反映的是文件系统整体空间，不能证明某个项目已经正确归集。项目 report 才能回答“这棵目录树用了多少、离软硬限制还有多远”。

上线前保留一份可回滚的判断清单

生产变更前，至少把下面几项写进变更单：

1. 目标路径通过 findmnt -T 确认为 XFS，挂载选项和发行版支持方式已核对。
2. /etc/projects、/etc/projid 已备份，project ID 没有和现有项目冲突。
3. project -s 后，report -p 能列出正确项目，目录树范围没有越界。
4. 容量和 inode 两种限制都按业务峰值设置，并完成受控写入与清理。
5. 回退方案包含恢复映射文件、撤销 limit 配置和再次执行 report 的验收动作。

相关问题

项目配额和目录权限是一回事吗？

不是。权限决定谁能访问，项目配额决定目录树累计能占用多少 XFS 资源，两者需要分别配置和验证。

为什么小文件场景要设置 inode 限制？

因为大量小文件可能先耗尽 inode，而不是先达到块容量上限；只设置 bsoft 和 bhard 会漏掉这条边界。

如何判断 report 的项目范围正确？

把一个受控测试文件写入目标目录，观察 report 使用量增加，再删除文件并确认使用量回落；同时检查目标目录之外的路径没有被纳入测试项目。

按目录树做 XFS 限额时，最小可靠闭环就是“挂载条件—项目映射—limit—report—受控写入”。任何一步只看配置文件、不看实际报告，都会留下配额形同虚设的风险。