UnionFS不提供存储容量规划或磁盘空间预警功能，其核心是分层叠加只读与可写层以实现镜像复用和容器隔离；真实容量监控须依赖宿主机磁盘感知能力，并结合上层工具链触发预警与清理策略。
UnionFS本身不直接提供存储容量规划或磁盘空间预警功能，它是一种分层文件系统技术，核心作用是按需叠加只读层与可写层，实现镜像复用和容器隔离。真正的容量监控与预警，必须依赖宿主机层面的磁盘空间感知能力，并结合上层工具链主动触发策略响应。
UnionFS分层结构对空间占用的真实影响
镜像由多个只读层构成，容器运行时新增一个可写层。所有写入（如日志、缓存、临时文件）都落在该可写层，而只读层被多个容器共享。这意味着：
- 镜像层大小固定，不随容器数量线性增长，但同一镜像不同版本（如
ubuntu:20.04vsubuntu:22.04）各自独立占用空间； - 容器可写层持续膨胀——比如未配置日志轮转的Docker容器，其
/var/lib/docker/overlay2/xxx/diff目录可能数日内增长至数十GB； - 删除容器不自动清理其可写层：只有执行
docker rm -v或使用docker system prune类命令，才会回收关联的可写层数据。
宿主机级磁盘空间监控是预警前提
UnionFS不暴露“剩余多少GB可用”这类指标，必须通过宿主机系统调用获取真实磁盘状态。例如：
- Linux下用
statvfs()或df -h读取/var/lib/docker所在挂载点的avail值； - 鸿蒙系统需调用
universal_disk_space等跨平台库，将底层statvfs封装为Dart可读模型，获取Total/Available/Used三元组； - 群晖NAS则需进入“存储管理器→使用情况”，区分共享文件夹、快照、LUN、Recycle等逻辑单元的真实占用，避免误判。
构建可落地的空间预警闭环
单纯知道“还剩15%空间”不够，关键在于触发可执行动作。推荐组合方式：
-
阈值分级告警：设置三级水位（如85%/90%/95%），分别触发企业微信通知、暂停新容器调度、自动执行
docker system prune -f --filter "until=24h"； -
绑定业务生命周期：在CI/CD流水线中，构建前检查
/var/lib/docker可用空间，低于阈值则中断构建并报错； -
清理策略前置化：Dockerfile中用
rm -rf /tmp/*清理构建中间产物；容器启动脚本内嵌logrotate配置或定期find /app/logs -name "*.log" -mtime +7 -delete。
特殊场景下的容量陷阱识别
以下情况极易导致磁盘“悄无声息”耗尽，需专项排查：
- 群晖回收站未清空：删除共享文件夹内文件后，实际仍占空间，须进控制面板→任务计划→添加“清空所有回收站”定时任务；
- 快照长期累积：Synology Snapshot或LVM快照保留策略过长（如默认90天），应缩至7–30天并批量删除历史快照；
-
统信UOS的root.disk虚拟盘膨胀：当系统以loop设备方式运行时（
/dev/loop0挂载root.disk），需用dd扩容文件+losetup -c+resize2fs三步完成扩展； -
隐藏日志文件霸占/data：统信桌面版常见于
/data/.xxx_log类隐藏目录，用sudo du -sh .[^.]*才能发现。
