Docker默认配置（overlay2驱动+常规文件系统）不支持单容器运行时磁盘配额，因overlay2底层不支持per-container rootfs空间限制；可行方案包括挂载宿主机XFS配额目录、tmpfs临时挂载及应用层监控。
Docker 默认存储配置（即使用 overlay2 驱动、宿主机为常规 ext4/XFS、未额外配置存储驱动）不支持对单个容器设置运行时磁盘配额。这不是配置遗漏，而是设计限制：overlay2 作为默认且最广泛使用的存储驱动，从底层就不支持 per-container 的 rootfs 空间上限控制。
也就是说，你无法通过 docker run --storage-opt size=2G 或在 docker-compose.yml 中写 storage_opt: {size: 2G} 来给一个容器硬性划出“最多用 2GB 磁盘”的边界——这条命令在 overlay2 下会报错或被静默忽略。
真正能落地的限制方式，必须绕开“容器 rootfs 配额”这个不可行路径，转而控制数据实际落盘的位置和方式：
挂载带配额的宿主机目录（推荐首选）
把易膨胀的数据（如日志、上传文件、缓存）单独挂载到宿主机一个已启用配额的路径：
✅ 前提：宿主机分区为 XFS，并挂载时开启prjquota（例如mount -o prjquota /dev/sdb1 /data）
✅ 操作：用xfs_quota为子目录设硬限，比如xfs_quota -x -c 'limit -p bhard=5g /data/app' /data
✅ 启动容器：docker run -v /data/app:/var/log/myapp nginx
→ 容器往/var/log/myapp写满 5GB 时，直接报Disk quota exceeded用 tmpfs 限制临时目录（轻量高效）
适合/tmp、/run、日志缓冲区等无需持久化的路径：
✅docker run --tmpfs /app/logs:rw,size=256m nginx
✅ 数据全程驻留内存/swap，不会写入磁盘，超限即报No space left on device
❌ 不适用于数据库数据、上传文件等需落盘场景应用层主动检查 + 清理（兜底必需）
单靠基础设施层限制不够，尤其对多租户或用户上传类服务：
✅ 在代码中定期调用df -h /path或os.statvfs()
✅ 达阈值（如 85%）时拒绝新请求、触发 logrotate 或清理过期文件
✅ 结合 Prometheus + Alertmanager 实时告警
Docker 默认配置下，CPU 和内存限制（--cpus, -m, --memory-swap）是可靠且推荐必配的；但磁盘空间限制必须借助宿主机能力或应用逻辑来实现，不存在“开箱即用”的单容器磁盘配额开关。
