storageopt 仅是向存储驱动传递参数的通道，实际磁盘配额效果取决于驱动支持（如zfs/btrfs支持、overlay2默认不支持）、宿主机配置及限制路径；更可靠方案包括tmpfs限制临时目录、xfs+prjquota实现宿主机级配额，并需应用层日志轮转与监控告警兜底。
StorageOpt 本身不是通用磁盘配额开关，它只是向底层存储驱动传递配置参数的“通道”。能否真正限制容器磁盘空间，取决于你用的存储驱动是否支持、宿主机是否已启用对应功能，以及你限制的是哪个路径（根文件系统？挂载目录？日志？）。简单说：不是所有 --storage-opt size=1G 都有效，很多场景下它会被忽略甚至报错。
看准存储驱动再动手
不同驱动对 StorageOpt 的支持差异极大：
-
overlay2（最常用）：默认不支持 per-container 磁盘配额。
--storage-opt size=1G在内核 ≥5.6 + 启用特定补丁时可能生效，但实际行为不稳定，且仅影响新镜像层大小上限，不是容器运行时的根目录配额。多数情况下会报错：Error: overlay2 does not support "size" -
zfs 或 btrfs：真支持。需宿主机已创建并启用配额的 ZFS 池（如
zpool create myzpool /dev/sdb），启动 dockerd 时指定--storage-driver=zfs，并在/etc/docker/daemon.json中配置{"storage-opts": ["zfs.poolname=myzpool"]}。之后每个容器自动对应一个 ZFS 子卷，再用zfs set quota=8G myzpool/docker/abc123手动设限。 -
devicemapper（已弃用）：曾支持
--storage-opt dm.thinpooldev等参数，但因复杂性和维护问题，Docker 官方早已不推荐，新环境请绕行。
更可靠：用 tmpfs 限制临时目录
如果你只想控制容器内某类易膨胀数据（比如日志、缓存、/tmp），tmpfs 是最轻量、最确定的方案——它把目录挂载到内存或 swap，天然受大小约束，且不写盘。
- 命令示例：
docker run --tmpfs /app/logs:rw,size=512m nginx - 效果：容器内
/app/logs最多用 512MB 内存/swap，写满即报 “No space left on device”，不会污染宿主机磁盘 - 适用位置：/tmp、/var/log、/run、自定义缓存目录等；不适合持久化数据
宿主机级配额：XFS + prjquota 最实用
这是生产环境最常用、最可控的方式——不限制 Docker 本身，而是限制它挂载的宿主机目录。
- 前提：宿主机分区为 XFS，并挂载时开启项目配额（
mount -o prjquota /dev/sdb1 /mnt/data） - 为目录设置配额：
xfs_quota -x -c 'project -s docker_app' /mnt/data（先标记目录），再xfs_quota -x -c 'limit -p bhard=2G docker_app' /mnt/data - 启动容器时挂载该目录：
docker run -v /mnt/data/app:/app nginx→ 容器对/app的写入就受 2GB 限制 - 优势：稳定、可动态调整、不影响其他容器、与存储驱动无关
别漏掉应用层和监控兜底
无论用哪种技术限制，都建议加两道保险：
- 容器内启用
logrotate自动轮转压缩日志，避免单个大日志撑爆空间 - 宿主机部署
docker system df -v或cadvisor + Prometheus，对Local Volumes和Build Cache设置告警阈值（比如 >85%） - 定期清理：
docker system prune -a --volumes（谨慎执行）
