先说一个我踩过的坑。几年前在维护一台共享计算服务器时，一个用户的离线任务在 /home 下生成了几百 GB 的临时文件，直接把根分区写满，数据库服务连不上去，全组人登录都开始卡。查到最后，就是那个用户脚本里的循环忘了清理中间产物。那次之后我就意识到：靠口头约定和自觉是不可靠的，共享环境里的磁盘必须从一开始就绑定强制的使用上限。这就是今天要聊的 Linux 用户磁盘配额（user disk quotas）——一套直接在内核层面生效、按用户或用户组做磁盘空间和文件数量强制限制的机制。它可以对 /home、/data、/tmp 这类共享目录做精细管控，能解决“一人写满、全盘遭殃”的典型问题。适合共享计算服务器、企业文件服务器、虚拟主机、GitLab Runner 缓存目录这类场景的管理员阅读，下面是我整理后的配置思路和完整实操过程。
1. 为什么需要磁盘配额：先想清楚再动手
1.1 配额能解决什么问题
先把这个问题的边界说清楚。磁盘配额解决的是“单一用户或单一用户组无节制占用共享存储”的问题，而不是“全局磁盘不足”的问题。全局磁盘不够，那是容量规划的事，哪怕给每个人都配了配额，总空间依然可能被所有用户合法用满。配额要做的，是在共享资源里给每个使用主体划定边界，保证一个人出问题时不拖垮所有人。
在很多运维团队里，共享服务器是靠“规定了每人只能用 50G”这种口头约束来管理的。但实际跑起来就会发现，约束只对自觉的人有效：批处理脚本写多了中间文件、日志没轮转、临时文件忘记清理，任何一个异常都能让整个分区爆掉。脚本巡检只能事后报警，而审计发现某用户超限往往已经晚了。配额机制最大的价值在于，它是内核在每次写入时强制检查的，不是靠某个进程自觉执行，也不需要额外守护进程一直盯着。
如果把磁盘比作一栋楼的总电表，普通做法是物业每个月看一下各户用电量，超过阈值再去提醒；配额机制则是给每家装了一个限流器，电流超了直接跳闸。跳闸虽然会影响这一户的写入，但避免整栋楼烧掉。对这个差别理解得越清楚，你越能明白为什么配额是共享文件系统上第一道防线，而不是可选项。
1.2 用户配额与组配额怎么选
配置之前，先想清楚限制主体是谁。用户配额（usrquota）按 Linux 登录用户生效，适合 /home、个人工作目录这类一人一块的场景。组配额（grpquota）按用户组生效，适合一个项目组共享一个目录池的情况：组里的每个人都往同一块空间写，但整个组的总用量不能超过某个值。
在实际生产环境里，两者可以叠加使用，并不冲突。比如你可以给每个用户设置 20G 软限制、25G 硬限制，同时给整个项目组设置 200G 的总限制。用户维度防止某个人独占，组维度防止某个项目整体失控。这样做的好处是覆盖面完整，缺点是配额文件里要管理的条目变多，后面做自动化脚本时要把用户和组两套逻辑都带上。
还要提一下项目配额（project quota），这是 XFS 文件系统上特别实用的另一种维度。项目配额不是按用户也不是按组，而是按目录打标记，适合容器存储、多租户平台这种“一个业务目录对应一个额度”的场景。如果你只是普通共享服务器，用户配额基本够用；如果是在做云平台或容器化改造，建议重点了解 XFS 的 prjquota，后面第 4 节我会再展开。
2. 配额的核心机制与准备工作
2.1 配额在文件系统层面如何生效
配额不是一个独立服务，而是文件系统模块的一份工作。Linux 内核在处理文件写入时，会经过通用的虚拟文件系统层，再落到具体文件系统上。以 ext4 为例，挂载时如果带上了 usrquota 选项，文件系统就会在每次写入、删除、修改属主等操作时，同步检查对应用户的配额计数。
这里有一点很多人容易忽略：配额依赖文件系统自身的支持，不同文件系统的实现方式差别很大。ext4 和老牌的 ext3 走的是“配额文件 + 挂载参数”这条路，需要在分区根目录下维护 aquota.user、aquota.group 这两个配额数据库文件。XFS 则是把配额信息直接放在文件系统的元数据里，不需要单独的配额文件，管理命令也变成了 xfs_quota。你在网上搜教程时，要先确认对方讲的是哪个文件系统，否则命令套上去大概率会报错。
内核版本和发行版默认配置也有影响。较新的 ext4 内核默认开启 quota 功能后，可能不需要你手动创建配额文件，tune2fs 甚至可以直接在超级块里启用 quota。但对大多数从零配置的服务器来说，传统流程依然最通用：改 /etc/fstab 挂载选项、重新挂载、初始化配额数据库、下发限制、启用配额。这套流程无论在 CentOS、Ubuntu 还是 RockyLinux 上都跑得通，也是下面实操部分采用的方法。
2.2 软限制、硬限制与宽限时间
配额限制分两个维度：容量（blocks）和文件数量（inodes）。容量维度限制用户能占用的磁盘块数，对应“能写多少字节”；inode 维度限制用户能创建的文件条目数，对应“能建多少个文件”。很多新手只限制容量，忽略 inode，结果用户在目录里生成几百万个空文件，把 inode 耗尽，df 一看还有空间，但文件系统就是无法再创建新文件，报 No space left on device。
每个维度又都分成软限制和硬限制。软限制（soft limit）是一个“提醒线”，用户超过这条线后可以继续写，但内核会记录违规状态，并开始消耗宽限期。硬限制（hard limit）是“绝对天花板”，一旦触及，写入直接失败，任何进程都绕不过去。硬限制通常比软限制大一些，留出缓冲，避免用户一超线就被强制拦住。
宽限期（grace time）是配额机制里最有意思的部分。默认情况下，用户超过软限制后，系统给 7 天时间让用户清理文件。在宽限期内，用户还能写入，只是不能超过硬限制；如果 7 天结束，用量还压在软限制之上，那么即使没到硬限制，内核也会拒绝新的写入，直到用户把用量降到软限制以下。这个设计很合理：软限制是“建议尽量别超过”，硬限制是“绝对不能超过”，宽限期则是“给你时间整改”。我见过不少团队只设了硬限制，软限制设成和硬限制一样，实际上等于把宽限期机制完全浪费了。
2.3 quota 工具链介绍
配置配额并不需要安装复杂服务，quota 工具包就是全部。在 Debian/Ubuntu 上安装命令是 apt install quota，RHEL/CentOS 系是 yum install quota。这个包里包含的命令都不算冷门，但你得先分清各自职责：
- quotacheck：扫描文件系统，生成或更新配额数据库文件。传统流程里第一步就是它。
- edquota：交互式编辑某个用户或组的配额值，适合单条调整。
- setquota：非交互式设置配额，适合脚本批量操作。
- quotaon / quotaoff：启用和停用某个文件系统的配额强制。
- quota：查询单个用户或组的配额使用情况。
- repquota：汇总报告整个文件系统的配额状态，运维巡检时最常用。
很多人容易把 quotaon 和挂载参数搞混。挂载参数是“允许这个文件系统启用配额功能”，quotaon 才是“现在启动强制检查”。修改 fstab 加上 usrquota 只是第一步，如果系统开机后没有自动执行 quotaon -a，配额并不会生效。好在大多数发行版的 systemd 环境下都有 quotaon.service，会读取 fstab 自动启用带配额选项的分区，但前提是你 fstab 里的挂载选项必须写对，这个后面排查章节会再强调。
3. 完整配置流程：从挂载选项到配额生效
3.1 修改挂载选项并重新挂载
假设有一块数据盘挂在 /data 上，文件系统是 ext4，接下来要同时启用用户配额和组配额。第一步当然不是直接敲命令，而是先备份 fstab，然后编辑挂载配置。
cp /etc/fstab /etc/fstab.bak vim /etc/fstab找到对应 /data 的那一行，在挂载选项里补上 usrquota,grpquota。修改完类似这样：
/dev/sdb1 /data ext4 defaults,usrquota,grpquota 0 2这里的关键点是：挂载选项一定要写进 fstab，而不是手动 mount 时临时加。只临时加参数，配额在本次运行期间是能用的，但服务器一重启就丢失，到时候你可能会收到一堆“磁盘写入失败”的告警，排查半天才发现是配额配置丢了。把这个选项固化到 fstab 里，是保证长期有效的最省心做法。
改完 fstab 后重新挂载让参数生效：
mount -o remount /data然后确认参数确实进去了：
grep quota /proc/mounts如果输出里有 usrquota,grpquota 字样，说明挂载参数没问题。这一步看似简单，但特别值得养成检查习惯，因为不少情况是 fstab 语法看起来没错，但 remount 时系统没按预期读取新选项，等到真正配置配额时才发现挂载选项根本没生效。
3.2 用 quotacheck 初始化配额数据库
挂载参数到位后，需要让内核先扫描一遍 /data 上现有的文件归属，生成配额数据库。传统工具是 quotacheck，具体命令：
quotacheck -cug /data参数里 -c 表示创建新的配额文件，-u 表示扫描用户配额，-g 表示扫描组配额。执行完成后，/data 下应该出现 aquota.user 和 aquota.group 两个文件：
ls -l /data/aquota.*如果文件生成成功，说明数据库初始化没问题。这里要提醒一句：quotacheck 不要在配额已经启用的情况下乱跑，否则可能造成数据不一致。最稳妥的顺序是：先确认 quotaoff，再执行 quotacheck。如果需要在一个正在生产使用的分区上做初始化，尽量选业务低峰期，因为扫描大文件系统时 I/O 压力不小，几 TB 的数据盘可能要跑十几分钟甚至更久。
还有一个常见情况：新版内核或某些发行版下，ext4 文件系统已经开启了内部 quota 标记，你会发现系统不让你创建 aquota.user，或者 quotacheck 报错说 quota file exists。这种时候不要强行删除系统文件，优先检查文件系统的 quota 状态，必要时用 tune2fs 查看有没有 quota feature，再决定走传统配额文件流程还是走内部 quota 流程。
3.3 用 edquota 和 setquota 下发配额
配额数据库准备好之后，就可以给用户设置限制了。单用户临时调整用 edquota 最直观：
edquota -u zhangsan执行后会进入文本编辑器，内容类似这样：
Disk quotas for user zhangsan (uid 1001): Filesystem blocks soft hard inodes soft hard /data 51200 0 0 1234 0 0其中 blocks 和 inodes 两列是当前实际使用量，soft 和 hard 分别对应软限制和硬限制。修改时只需要把对应数字填进去，保存退出即可。这个交互式编辑适合处理个别人的异常需求，比如某个项目临时需要调大空间。
但如果用户数量很多，edquota 一条条编辑会非常痛苦，这时候用 setquota 才是正解。例如给 zhangsan 设置 500M 软容量、600M 硬容量、5 万个 inode 软限制、6 万个 inode 硬限制：
setquota -u zhangsan 512000 614400 50000 60000 /data很多人会对数字的单位有疑问。这里的容量单位是 1024 字节的块，也就是 512000 约等于 500MB，614400 约等于 600MB。inode 维度没有歧义，就是文件个数。如果你不想限制 inode，把后两个数字都设为 0，0 表示不限制；同样的，容量维度设为 0 也代表不做限制。
组配额的操作逻辑完全一样，只是把 -u 换成 -g，例如给 ops 组设置总容量限制：
setquota -g ops 2048000 2560000 0 0 /data这条命令把 ops 组的容量软硬限制分别设为约 2G 和 2.5G。需要注意，组配额限制的是该组所有成员在 /data 上的总占用，不是组内每个用户各自的分量。如果目标是“每人 20G，组总共 200G”，用户配额和组配额必须同时配置，缺一不可。
宽限时间也可以用 edquota -t 调整。默认 7 天可能太长，对于临时任务密集的服务器，我个人习惯把容量宽限期改成 3 天甚至 1 天：
edquota -t编辑器里会出现 block grace time 和 inode grace time 两项，改成自己期望的时间后保存即可。宽限期设置得短一些，逼着用户尽快清理，对磁盘健康更有利，但也要考虑业务方实际清理的时间窗口，别把人家正常任务全卡死。
3.4 启用配额并验证效果
限制配好后，需要正式启用配额强制机制：
quotaon /data如果想确认状态，可以用 quotaon -p /data 查看启停情况。启用后，建议立刻做一次验证，确认配置真的生效了。先看用户视角：
quota -u zhangsan /data再看整个文件系统的汇总视角：
repquota -arepquota -a 会列出所有带配额文件系统的用户或组用量，包含 soft、hard、grace 时间和当前状态。我通常会在配置完成后把 repquota 的结果存一份快照，后面巡检时用来对比增量，排查异常增长非常方便。
验证时还可以用一个更直接的办法：切到 zhangsan 身份，尝试写一个超过硬限制的文件，确认系统返回 Disk quota exceeded。这种“故意写爆”的测试建议在测试环境做，生产环境做之前一定和业务方确认，以免影响别人的正常任务。测试完再删除测试文件，配额占用会自动回落。
3.5 批量下发配额的自动化写法
真正管几十上百个用户的服务器，手动逐条 setquota 不现实。我习惯把用户名单放进一个文件，循环下发：
#!/bin/bash for user in $(cat /root/scripts/quota_users.txt); do setquota -u "$user" 512000 614400 50000 60000 /data done quotaon /data repquota -a > /root/scripts/quota_report_$(date +%F).txt这个脚本看起来简单，但有三个细节值得注意。第一，用户名单最好用 uid 或从用户数据库导出，避免误把已删除用户写进去。第二，脚本前先做一次配额状态清理，确保没有残留的旧配额值，否则重复执行会覆盖掉之前的个性化调整。第三，批量执行后必须检查返回值，可以给 setquota 加上失败退出逻辑，不要眼睁睁看着大量命令报错还在继续循环。
如果想做得更精细，还可以按用户组设置不同的配额模板，比如普通员工和研发组用两套标准。把这套逻辑写成函数，维护成本会低很多。我的习惯是放一个模板配置文件，里面定义默认软硬限制和 inode 限制，脚本读取后按用户环境变量或组成员身份套用，这样后续调整额度只改模板，不用改脚本。
4. 常见问题与排查技巧实录
4.1 quotacheck 报错与配额文件缺失
最常遇到的问题是 quotacheck 执行失败，提示 can't open quotafile 或者找不到挂载点。这类问题八成是挂载参数根本没生效。我曾经遇到过一台机器 fstab 里写了 usrquota，但实际挂载参数里没有，原因是那次挂载是用 mount 命令手工做的，并没有读取 fstab。所以排查的第一步永远是看 /proc/mounts：
grep /data /proc/mounts如果输出里没有 quota 字眼，说明参数没生效，需要回到挂载环节解决。这时候不要急着 remount，正确做法是先确认 fstab 内容没问题，再 cat /proc/mounts 对比实际情况。
另一种情况是文件系统已经启用了配额，但你重复执行 quotacheck -c 时系统拒绝覆盖正在使用的配额文件。先停用配额再扫描：
quotaoff /data quotacheck -cug /data quotaon /data顺序绝对不能反，否则配额文件会被正在运行的配额机制占用，扫描结果也可能不一致。对大型文件系统，这一步最好在业务维护窗口执行，避免配额数据库重建期间用户写入状态出现短暂异常。
还有一个比较隐蔽的问题：/data 目录的挂载属性是 ro（只读），或者被 SELinux 策略干扰。只读挂载下 quotacheck 创建不了配额文件，SELinux 则会拒绝 quota 工具访问某些文件。遇到这种情况，检查挂载属性和审计日志，不要一上来就禁用 SELinux，大部分情况是文件上下文标签不对，用 restorecon 或 semanage 调整即可。
4.2 配额不生效
配额配置完，用户写入却完全没有被限制，这种问题在群里被问过无数次。如果你确认挂载参数和 quotaon 状态都正常，接下来按几个方向逐个排查。
先检查配额是否真的启用了强制检查：
quotaon -p /data输出会显示 user quota 和 group quota 的启停状态。如果显示 on，再看实际用户：
quota -u zhangsan /data如果显示 no limits 或 nothing，说明是 setquota 时写错了参数或写错了路径。最常见的是硬限制写成了 0：在 setquota 语法里，0 表示不限制，如果你把一个字段误写成 0，配额自然拦不住。我之前就见过有人把 50000 误输成 0，然后疑惑为什么配额没生效。
还有一个很容易被忽视的点：root 用户（uid 0）在大多数实现里默认不受配额限制。即使你在 /etc/fstab 里配了配额、给 root 设了限制，内核也可能直接放过 root 的写入。这不是 bug，而是设计如此，毕竟 root 要能做系统维护。如果业务场景是容器或虚拟化，宿主机上以 root 跑的进程往共享目录写入时，配额几乎约束不到，需要在更底层做隔离，这也是为什么容器场景下要优先考虑 XFS 项目配额或者存储后端的配额能力。
最后看 quotaon 服务是否开机自启。有些精简系统只安装了 quota 包，但没启用 quotaon.service，服务器一重启，配额就处于关闭状态。检查一下 systemd 服务：
systemctl status quotaon.service如果服务没启用，及时设置开机自启。这一步做完，配额才不会在重启后莫名其妙的集体失效。
4.3 宽限时间与 inode 配额
很多人把配额理解为“超过硬限制就禁止写入”，但软限制和宽限期的组合经常带来困惑。举一个真实情况：用户超了软限制，宽限期还剩 3 天，这时候他写入 100M 文件成功了，但过了宽限期后，哪怕他的用量仍然在硬限制之内，也写不进任何东西。业务方这时候报障“磁盘空间还剩很多，为什么写不进去”，多半就是这个原因。
排查方法就是查看这个用户的 grace 状态：
quota -u zhangsan /data如果 grace 列显示超时或者状态是 in grace，就该让用户清理数据，或者临时调高软限制。调高软限制后，宽限期记录会被重置，这种操作适合处理紧急业务恢复，但别把调额当常态，否则软限制就失去意义了。
inode 配额的问题比容量配额更容易被忽视。一群微服务跑在共享存储上，每个服务都生成大量小文件、临时文件，一天几百万个文件很正常。这种情况下容量配额是够的，但 inode 可能先被打爆。判断是不是 inode 配额导致的写入失败，先看 df -i：
df -i /data如果文件系统 inode 总数还剩不少，但某个用户创建文件时报错，再看用户的 inode 限制。设置 inode 配额时别忘了考虑业务特性，日志型目录、消息队列目录都要预留更大余量，否则业务方会在毫无征兆的情况下突然无法创建文件。
4.4 文件系统差异：XFS 与 NFS 场景
ext4 的配额流程在 XFS 上行不通，这是最容易踩的坑。XFS 不需要 aquota.user 和 aquota.group，也不建议用 quotacheck。启用时在挂载选项里加 uquota,gquota，管理用 xfs_quota 工具。设置用户限制的典型写法：
mount -o uquota,gquota /dev/vdb1 /data xfs_quota -x -c 'limit -u bsoft=500m bhard=600m isoft=50000 ihard=60000 zhangsan' /data xfs_quota -x -c 'report -u' /data注意这里的单位可以直接写 m、g，比 setquota 的块数直观得多。xfs_quota 的 report 输出列也比较清晰，适合直接对接监控脚本。XFS 还支持项目配额，通过 prjquota 挂载参数和 project ID 给目录配额，这是 ext4 不容易做到的。如果公司在做容器化存储方案，我强烈建议优先考虑 XFS 加项目配额，它能把“一个挂载点、多个业务目录、各自独立限额”的需求做得非常干净。
至于 NFS 共享目录的配额，情况又复杂一层。配额强制主要发生在 NFS 服务端所在文件系统上，客户端写文件时，由服务端内核做检查。客户端想查询配额，需要服务端跑 rpc.rquotad 之类的守护进程，同时客户端也要装 quota 包。因此我的建议是：NFS 配额场景先保证服务端文件系统配额正确，再考虑客户端查询展示，不要指望客户端本机做限制。NFS 版本、导出选项和 fstab 的 netdev 参数都会影响最终效果，生产环境一定要先在测试环境完整验证一遍。
最后一点个人经验
配额配置这件事，技术上不复杂，真正难的是想清楚管理策略。我后来把所有重要共享文件系统的配额都写成了配置脚本，用户名单和额度模板统一放在一个目录里管理，同时在监控平台上定时拉取 repquota 输出，设置超限告警阈值。这样既能靠内核强制兜底，又能靠监控提前发现那些没到硬限制但已经持续增长的隐患。配置配额时宁可一开始保守一点、预留调整空间，也别等磁盘爆了再熬夜救火。实际操作中如果拿不准某个参数的影响，先在临时目录或测试分区上完整跑一遍流程，观察几天再上生产，会比直接在生产环境冒险稳妥得多。
