先说一个我踩过的坑。几年前在维护一台共享计算服务器时一个用户的离线任务在 /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 quotaRHEL/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 约等于 500MB614400 约等于 600MB。inode 维度没有歧义就是文件个数。如果你不想限制 inode把后两个数字都设为 00 表示不限制同样的容量维度设为 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 执行失败提示 cant open quotafile 或者找不到挂载点。这类问题八成是挂载参数根本没生效。我曾经遇到过一台机器 fstab 里写了 usrquota但实际挂载参数里没有原因是那次挂载是用 mount 命令手工做的并没有读取 fstab。所以排查的第一步永远是看 /proc/mountsgrep /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 -idf -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 bsoft500m bhard600m isoft50000 ihard60000 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 输出设置超限告警阈值。这样既能靠内核强制兜底又能靠监控提前发现那些没到硬限制但已经持续增长的隐患。配置配额时宁可一开始保守一点、预留调整空间也别等磁盘爆了再熬夜救火。实际操作中如果拿不准某个参数的影响先在临时目录或测试分区上完整跑一遍流程观察几天再上生产会比直接在生产环境冒险稳妥得多。