WSL 磁盘占用暴涨时，如何只读定位而不误删数据
从一次真实的 180 GB 空间调查出发，建立 WSL、Docker、Kind 与任务运行时的分层只读排查方法。
WSL2 的虚拟磁盘变大后，第一反应常常是运行某个“一键清理”。但在开发机上，大目录可能同时属于 Docker、Kind、模型缓存、构建产物和正在运行的分布式任务。没有确认所有权就删除，省下的磁盘很可能换来不可恢复的数据。
一次历史 Codex 会话里，我收到的约束很明确：只调查，不删除、不修改。最终的大头不是普通包缓存，而是一套已经遗留的 Ray/Kubernetes 运行数据，单项约 180 GB。这个过程很适合作为只读磁盘审计模板。
先分清三个不同的“占用”
WSL 磁盘问题至少有三层数字：
- Linux 文件系统中的已用空间；
- 目录和文件的逻辑/实际占用；
- Windows 上
ext4.vhdx的文件大小。
删除 Linux 文件后，第一层会立即下降，但第三层通常不会自动缩小。VHDX 只是把空闲块标为可复用，并不保证宿主文件立刻收缩。因此调查阶段不要用 Windows 文件大小反推“删除没有生效”，也不要把虚拟盘压缩与 Linux 文件清理混成一步。
第一轮只建立全局基线：
1
2
3
4
df -hT
df -ih
du -xhd1 / 2>/dev/null | sort -h
du -xhd1 "$HOME" 2>/dev/null | sort -h
-x 避免跨到挂载的 Windows 盘或其他文件系统；inode 检查则能识别“大量小文件”导致空间看似还有、创建文件却失败的情况。
从大目录追到资源所有者
找到大目录后，不要立刻 rm -rf，而要继续问它属于谁。常见路径可按来源分组：
/var/lib/docker：镜像、容器可写层、volume 与 build cache；- Kind/K3s/Kubernetes 节点数据：容器运行时、Pod volume、日志；
~/.cache：Hugging Face、pip、uv、编译缓存；- 项目工作区：数据集、checkpoint、构建目录、测试产物；
/tmp、/var/tmp：Ray、Dask、浏览器、安装器的会话目录；- 日志：systemd journal、容器日志、长期后台任务输出。
文件系统只告诉你“哪里大”，控制面才能告诉你“是否仍在使用”。例如 Docker 应同时查看：
1
2
3
4
docker system df -v
docker ps -a --size
docker volume ls
docker builder du
Kind 或 Kubernetes 还要检查集群、Pod、PVC 与节点状态。一个 volume 在宿主上看似孤立，可能仍是某个暂停容器或集群节点的唯一数据盘。
为什么运行时目录会悄悄长到百 GB
Ray、Kubernetes 与训练任务会同时产生对象存储、worker 日志、临时文件和本地 volume。任务结束不完整、控制面异常退出或重复创建集群时，运行资源可能已经不存在，但 kubelet/volume 目录仍留在磁盘。
那次审计中，最大的 180 GB 路径与 Ray 集群的 kubelet 数据对应；外层 Docker 与 Kind 自身还有独立占用。关键不是认出目录名里有 ray 就删除，而是把以下证据串起来：
- 目录大小和最后修改时间；
- 对应容器、Pod、集群是否存在；
- 挂载关系和打开文件；
- 任务是否仍有进程；
- 用户是否需要保留 checkpoint、日志或对象。
可以使用 lsof +D 时要注意，大目录递归可能很慢；更实用的是先查挂载与进程，再对候选子目录缩小范围。
调查与清理必须是两次授权
只读请求的交付物应该是一张清单，而不是一个变干净的磁盘。每个候选项至少列出：路径、大小、来源、是否活跃、删除影响、推荐的拥有者命令和可恢复性。
例如 Docker 资源优先通过 Docker CLI 删除，Kind 集群通过 kind delete cluster，Ray/Kubernetes 工作负载通过其控制面终止。直接删底层存储目录可能绕过元数据更新，使运行时进入更难修复的不一致状态。
只有用户明确选择某一项后，才进入第二阶段，并在操作前后记录 df、目标大小和保留项。那次会话后来单独获得了清理授权，释放约 180 GB，同时保留 Kind、其他 Docker 镜像和用户文件。这个顺序比“先删了再解释”重要得多。
释放空间后还有最后一层
Linux 文件系统空间下降后，如果 Windows 宿主仍需要回收 ext4.vhdx 的物理文件大小，应先完全关闭 WSL，再使用 Windows 支持的虚拟磁盘压缩流程。这个动作影响的是宿主 VHDX，不应与 Linux 内部清理同时自动执行。
磁盘审计的核心并不是熟记哪条 du 命令，而是保持证据链：空间属于哪个文件系统、哪个目录、哪个运行时对象、哪个仍然活跃的任务。只要所有权没有确认，“大”本身从来不是删除理由。