配额文件位于启用配额的文件系统根目录下，即 aquota.user 和 aquota.group，如 /home/aquota.user；它们是二进制格式，由 quotacheck 生成，不可直接读取，需用 sudo ls -lh 等命令验证存在且非空。
配额文件在哪？直接看 aquota.group 和 aquota.user
Linux 的磁盘配额数据不存数据库里，而是写在每个启用配额的文件系统根目录下的两个二进制文件中：aquota.user（用户配额）和 aquota.group（组配额）。它们默认不可读，但路径固定、位置明确。
比如你对 /home 启用了组配额，那配额数据就存在：/home/aquota.group；对 /data 启用用户配额，对应文件就是：/data/aquota.user。
- 这些文件由
quotacheck生成或更新，普通用户无权读取，必须用sudo查看 - 直接
cat /home/aquota.group会输出乱码——它是二进制格式，不是文本 - 想确认文件是否存在且非空，可用：
sudo ls -lh /home/aquota.group或sudo file /home/aquota.group - 若文件不存在或大小为 0，说明配额未初始化或损坏，需运行
sudo quotacheck -vg /home重建
quotacheck -m 能否绕过只读挂载直接读配额文件？
不能。即使加了 -m（跳过重新挂载为只读），quotacheck 仍需扫描整个文件系统 inode 来统计真实用量，这个过程依赖底层文件系统一致性。如果分区正在被写入（比如有活跃进程在 /home 下创建文件），quotacheck 可能读到中间状态，导致配额账本不准。
-
-m只是避免临时 remount -o ro，不等于“跳过校验” - 生产环境建议在低峰期执行：
sudo quotacheck -avug（全系统检查用户+组） - XFS 文件系统例外：它把配额信息内建在元数据里，不需要
aquota.*文件，所以quotacheck对 XFS 是无效命令 - ext4 等传统文件系统必须依赖这些文件，且它们必须位于对应挂载点根目录下，不能挪动或软链
为什么 repquota -g groupname 报 “No such process”？
这不是找不到组，而是配额子系统根本没加载——内核没看到配额文件，或者没启用配额功能。常见原因有三个：
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
/etc/fstab里对应分区缺少grpquota（组）或usrquota（用户）挂载选项，比如该行漏了,grpquota - 虽改了
/etc/fstab，但没运行sudo quotaon -avug激活配额，或重启后没自动生效 -
aquota.group文件权限不对（比如被误 chmod 600 成只有 root 可读，而 quotaon 需要其他权限） - 注意：
quota -g groupname和repquota -g groupname都依赖同一套底层数据，报错逻辑一致
怎么验证配额文件内容是否可信？
最直接的办法是交叉比对：用 du 手动统计 + quota 查询结果是否接近。比如查 devteam 组在 /home 的用量：
先手动算：sudo find /home -group devteam -type f -print0 | xargs -0 du -sk | awk '{sum += $1} END {print sum/1024 " MB"}'
再查配额：sudo quota -g devteam -s /home
- 两者差值超过 5% 就值得怀疑——可能是配额文件陈旧，或有硬链接、ACL、稀疏文件干扰统计
- 这时必须运行
sudo quotacheck -vg /home强制重扫，而不是只靠quotaon刷新 - 别依赖
df输出：它显示的是整个文件系统用量，不区分用户/组，和配额无关
配额文件本身不提供人工可读的摘要，它的“可信度”永远取决于 quotacheck 扫描那一刻的真实性和完整性。运维上最容易忽略的，就是以为改完 /etc/fstab 就万事大吉，却忘了跑 quotacheck 和 quotaon 这两步。
