我们有一台共享存储机器，硬盘是 2TB 的 XFS 阵列，上面跑着 30 个业务方的小程序。开始的时候是裸奔的谁都能往里写，结果一个跑日志的服务两天就塞进去 400G，另一个人想上传素材，直接写不进去了。运维同事说，这事得用磁盘配额管起来，每家 50G，超了直接写不进去，别的不受影响。我以前只在 CentOS 上用过 quota，这回机器换成了 Ubuntu，XFS 上的xfs_quota和 ext4 的 quota 完全是两套东西，踩了几个坑，记一下。
如果你也在给共享服务器划空间，先看看这几家的报价和技术说明：ColoCrossing（美国数据中心，提供大容量存储型独立服务器与云主机），存储量大、目录多的场景可以先拿他们的存储方案对比一下容量和硬盘口径。
一、第一处坑：mount 时没加 uquota，配额写了等于没写
我第一次配的时候，直接建了 project、设了 limit，然后让用户往里写结果写进去了，xfs_quota -x -c 'report' /data 里 limit 显示 50G，可实际用量能超过 50G 后来回上下跳，quota 查出来还是 blank。
原因在于 XFS 的配额功能不是内核里默认打开的开关，它靠挂载参数启用。必须重新挂载这个文件系统并带上 prjquota（项目配额）或 uquota（用户配额），否则内核压根不维护这些计数，你后面怎么设都是空的。
实操上我用的是项目配额（project quota），因为它绑定的是目录树上的一个 project id，而不是 Linux 用户名。这样每个客户的目录可以是一个独立 project，程序里的运行用户换不换都不影响。
改 /etc/fstab 的时候要注意，把原来的挂载项整行换掉，别写成两条同目录的挂载记录我第一次就是这么干的，结果 mount 时报 “mount point is busy”，改完还得重启机器才生效。
二、第二处坑：project id 是 32 位数字，还得避开保留段
建 project 的命令看着简单：
xfs_quota -x -c 'project -s -p /data/clients/aaa 101' /data
这里的 101 就是 project id。它的取值范围是 32 位无符号整数，但文档明确说 0 和 1 是保留的，实际用的时候从 10 开始往上排比较保险。另外这个 id 一旦分配给某个目录，就不要再改目录树里的 inode 都记着这个 id，改了等于把已有配额信息全部孤立掉，得重新初始化。
我这里踩的第二个坑是路径写成了相对路径。xfs_quota -x -c ... 这条命令执行时的当前目录会影响你写相对路径的解析，我在 /root 目录下敲的命令，写 clients/aaa 结果没匹配上，报了个 “No such project”。后来统一改成绝对路径 + -s 开关（意思是创建时允许设置 limit），才一次过。
还有个细节：-p 指定的项目路径，必须是当前挂载点下的目录，且写入 quota 的时候目录要已经存在。目录是空的、还没 mkdir 的话，命令不会替你创建。
三、第三处坑：软限制和硬限制不是一回事
xfs_quota 的 limit 分两档：soft（软限制）是给用户一个缓冲区，到线之后会收到警告，但还能继续写；hard（硬限制）是天花板，撞上去立刻返回 EDQUOT，写不进去。
最直接的写法是 bsoft=50g bhard=50g，软硬都设成 50G，也就是到线就断。也可以写成 bsoft=45g bhard=50g，留 5G 的缓冲，让服务在完全写死之前先收到告警，自己去清理。
我给每个客户都设了 soft 45G / hard 50G，理由是：直接 hard 50G 卡死的话，客户端往往只看到一个 “No space left on device” 或者 quota 类错误，日志里看不出是谁超了；留 5G 软限制的话，配额系统会先打日志告警，我们巡检时能提前介入。真要更狠一点，也可以用 rtinh=1 把软限制变成“宽限期”，也就是过了软限制之后还允许继续写，但系统会主动回收老文件腾地方这个我没敢在生产上开，属于兜底手段。
四、配额跑起来之后，怎么确认它真的在拦人
光看 report 不够，得实测。我让测试客户往目录里写大文件，写到软限制时先看告警日志，再写到硬限制时确认写入真的失败、而且别的 project 完全不受影响。这一步是必须的XFS 的配额是按 project 隔离的，理论上互不干扰，但你得亲眼看到别的客户还能正常写，才算这事儿落地。
日常巡检我一般跑这三条命令：
xfs_quota -x -c 'report -h' /data 看所有 project 的用量排行，一眼看出谁快满了；
xfs_quota -x -c 'limit -p bhard=50g bsoft=45g 101' /data 临时给某个 project 调额度，客户临时有大促要扩容时用得上；
xfs_quota -x -c 'state' /data 确认文件系统确实处于启用配额的状态。
另外要留意 inode 配额。空间没满但文件写不进去，很可能是 inode 用光了小文件多的场景（比如某个客户不停写缓存碎片）会先撞到 inode 上限。XFS 的 inode 数量是在建 fs 时用 -i maxpct= 定的，mkfs 之后就固定了，所以生产盘最好在文件系统层面就把 inode 数量规划好。
五、什么场景不适合用 xfs_quota
最后说点不适合的。第一，如果你的目录是 Docker 容器挂载出来的 volume，容器里的写配额和 XFS 的 project id 不是一个体系，容易对不上号，建议容器那边单独用 --storage-opt size= 控制，别混着来。第二，如果用的是 ext4 或者 overlay2（容器默认），xfs_quota 这套命令是不适用的，ext4 有自己的 quota 工具。第三，配额只能管空间和 inode，管不了 IO 带宽和 IOPS，一个客户就算只占 1G，也可能把整块盘的 IO 打满，那种场景得靠 cgroup 或者存储层的限速。
整体下来，xfs_quota 这套东西配置量不大，真正花时间的是想清楚三件事：挂载参数别漏、project id 别乱用、软硬限制要想明白。这三个坑我各踩了一次才彻底搞明白，希望你不用重走一遍。
工具方面，如果想先在本地把目录占用情况看清楚再决定怎么划配额，可以用 NcduWin 这类 ncdu 风格的磁盘空间分析工具跑一遍，它能按目录逐层展开，比 du 一行行敲命令直观得多。
喜欢 
顶
难过
囧
围观
无聊
