项目配额（prjquota）是最可靠的日志目录硬限制手段，因其在内核层实时拦截写入、不依赖用户态服务；需挂载启用prjquota、配置/etc/projects与/etc/projid、执行project -s初始化、再用xfs_quota -c 'limit -p bhard=5g'设硬限。
直接用 XFS 项目配额（prjquota）给日志目录设硬限制，是最有效的主动防御手段——它不依赖日志轮转是否及时、脚本是否运行、服务是否重启，而是在内核层拦截写入，从源头掐断“爆满”可能。
为什么项目配额比软性清理更可靠
日志清理（如 logrotate 或 find + rm）属于事后补救：一旦写入速度远超轮转频率（比如突发错误风暴每秒生成百MB日志），磁盘仍可能在几秒内被填满。而项目配额是实时生效的强制策略，只要目录树总用量触及硬限制，后续 write() 系统调用立即返回 ENOSPC 错误，应用日志写入失败但不会拖垮整个系统。
- 用户配额（usrquota）和组配额（grpquota）无法精准约束 /var/log/nginx 或 /var/log/app 这类专用日志路径，因为日志进程通常以非特权用户运行，且多个服务混用同一用户
- 项目配额绑定目录树（project ID），无论哪个进程往该目录及其子目录写文件，都统一计入配额，天然适配多服务日志隔离场景
- 配额由 XFS 文件系统在挂载时启用，在 VFS 层拦截，不依赖用户态服务，即使 rsyslog 崩溃、journald 卡死，限额依然有效
四步完成日志目录项目配额配置
以限制 /var/log/myapp 目录总用量不超过 5GB 为例：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
-
确认文件系统支持并已挂载 prjquota：运行
mount | grep "$(df -P /var/log/myapp | awk 'NR==2 {print $1}')"，输出中需含prjquota；若无，需编辑/etc/fstab，在对应行 options 字段追加,prjquota，再执行mount -o remount /var/log/myapp -
为目录分配唯一 project ID 并初始化：创建
/etc/projects，添加一行1001:/var/log/myapp；再创建/etc/projid，添加myapp:1001；最后运行xfs_quota -x -c 'project -s myapp' /var/log -
设置硬限制（关键！）：执行
xfs_quota -x -c 'limit -p bhard=5g myapp' /var/log；bhard是硬块限制，单位可为 k/m/g；不设软限制（bsoft）可避免警告期风险 -
验证生效：用
dd if=/dev/zero of=/var/log/myapp/fill bs=1M count=6000尝试写入 6GB，当达到 5GB 时命令会报错No space left on device，且xfs_quota -x -c 'report -bp' /var/log显示 usage 已达 hard limit
配合监控与冗余的实用建议
配额不是“设完就完”，要让它真正扛住生产压力：
- 在 Prometheus + node_exporter 中，用
node_filesystem_files_free{mountpoint="/var/log"} / node_filesystem_files_total{mountpoint="/var/log"}配合xfs_quota -c 'report -bp'的解析结果做双维度告警，避免仅看 df 导致误判 - 对核心日志目录（如 /var/log/messages 所在分区），预留 10%~15% 空间不纳入任何项目配额，留给 kernel log、emergency shell 日志等关键路径
- 若使用容器化部署，可在宿主机为每个容器日志目录（如 /var/lib/docker/containers/xxx/xxx-json.log 所在父目录）单独设 project，避免单个容器打爆整机日志盘
- 定期检查
xfs_info /var/log输出中的projquota是否为enabled，防止因 fstab 修改未生效或 remount 失败导致限额静默失效
项目配额不是替代日志轮转，而是兜底防线。清理负责“常态瘦身”，配额负责“极端止血”。两者叠加，才能让日志盘真正稳如磐石。
