AutoDL回收站清理：彻底释放GPU云服务器磁盘空间

谁还没在AutoDL上删错过文件？更准确点说，谁没在AutoDL上删完一堆大文件之后，发现磁盘占用率依然红得发紫？我第一次踩这个坑是在一次模型评测的间歇，系统盘只剩2GB，但我明明已经把一个十几GB的权重文件从目录里拖出去删了。痛定思痛，顺着目录一个个比大小，最后才发现东西全安安静静躺在回收站里。那会儿我就意识到，光在网页端点删除根本没用，回收站里的文件如果不彻底清理，磁盘计费照样一分不少。

AutoDL这类GPU算力平台最大的特点是“按量计费、按需扩容”，用户在本地写代码可能几十GB就够用，但放到这里，数据集、权重、日志随便一凑就是上百GB。偏偏平台的文件管理器出于安全考虑，默认把网页端点的“删除”变成“移入回收站”，并不会真正释放空间。你要是不知道回收站实际路径，或者只在网页端做初级清理，那磁盘永远处于一种“明明删了，但好像没删”的诡异状态。

这篇文章主要给在AutoDL上跑训练、跑数据实验的同学一份可复现的清理方案：讲清楚AutoDL回收站的原理和存放路径，给出命令行彻底清理的完整流程，再补充我几次清理经验里踩过的坑和排查方法。适合那些已经在AutoDL上部署过任务、对Linux基础命令不陌生、但还没把存储管理彻底搞明白的朋友。

1. 回收站的真相：为什么明明删了，空间依然被占

1.1 AutoDL文件管理器的“伪删除”

用AutoDL网页端的文件管理，点删除按钮时，提示文字通常会写“已移入回收站”。很多同学点完就不管了，继续跑下一个训练任务，结果磁盘占用率依然在90%以上晃悠，接着遇到各种“No space left on device”的报错。这里的原因要从文件系统层面来看。

常规的Linux桌面环境，删除文件时如果选择“移到回收站”，系统做的事并不是把数据抹掉，而是把文件重命名并挪到特定目录下，例如/root/.local/share/Trash/files/。文件占用的数据块没有真正注销，在df -h里自然看不到可用空间增长。AutoDL网页端的文件管理器做的就是同样的事：它调用的不是rm，而是mv，界面上写着“已删除成功”，但存储占用和计费上一切照旧。

所以第一步要建立的概念是：网页端的“删除”不等于释放空间，充其量只是把文件挪到了一个软删除区。真要省空间，必须再往前走一步——彻底清理回收站。如果你只清到一半，那跟没删基本没什么区别。

1.2 回收站到底藏在哪里

从我的使用经验来看，不同镜像、不同时间开通的AutoDL实例，用户目录结构大体一致，但回收站路径可能存在差异。最靠谱的方法不是背路径，而是用命令去找：

find /root -maxdepth 4 -type d \( -iname "*trash*" -o -name ".Trash*" \) 2>/dev/null

这条命令会在用户目录下寻找名字里带trash的文件夹。常见的几种路径我列在这里，方便各位对照排查：

这里有个容易忽略的点：数据盘上的文件被网页端删除后，回收站未必在/root/.local/share/Trash里，也可能直接出现在/root/autodl-tmp下的隐藏目录。所以排查时别只盯着系统盘那个回收站，/root/autodl-tmp下面也得翻一翻。如果你习惯用VNC图形桌面里的文件管理器做删除操作，回收站机制同样生效，路径也绕不开上面这几个位置。

2. 清理前先诊断：磁盘占用怎么算数

2.1 两条命令摸清家底

在没有真正动手清理之前，先搞清楚一个核心问题：空间到底是被什么吃掉的？是回收站里的软删除文件，还是目录下真实存在的数据？这时候两条命令就够用。

df -h /root /root/autodl-tmp du -sh /root/* /root/.* 2>/dev/null | sort -rh | head -20

df -h看的是文件系统级别的使用量，du -sh看的是目录级别的实际占用。把它们对比起来看就能发现很多问题。举个例子，df显示/root已经用了80GB，但du -sh /root/*把所有可见文件加起来只有50GB，这中间30GB的差额，大概率就是隐藏目录（包括回收站）占掉的空间。反直觉的是，du -sh /root/*默认不统计点开头文件，所以一定要把/root/.*带上，否则永远只看到一半的真相。

我第一次排查的时候就是栽在这一步，光盯着du -sh /root/*看了老半天，怎么算都对不上，后来把隐藏目录加进去才发现回收站里躺着一堆几十GB的旧checkpoint。

2.2 系统盘与数据盘要分开看

AutoDL的存储结构通常是两个挂载点：系统盘/root空间较小但是装了环境、日志和缓存，数据盘/root/autodl-tmp容量更大，专门用来放大文件。清理回收站时，先确认一下要清的文件来源：如果删除的是数据盘上的文件，回收站文件多半在/root/autodl-tmp对应的隐藏目录下；如果删的是系统盘文件，/root/.local/share/Trash才是主战场。

实际操作中遇到过有人清了半天系统盘的回收站，结果发现数据盘占用率一点没动，原因就是他把大批数据集的临时文件放在/root/autodl-tmp下删除，回收站也落在了数据盘。所以动手前先跑一条df -h，看看到底是哪个盘告急，再顺着对应的目录去清，这样效率高得多。

3. 实操：命令行彻底清理回收站的全流程

3.1 定位回收站并确认占用大小

确认回收站路径之后，先看看它到底占了多少空间，顺便检查一下里面还有什么东西，免得误删了还有用的文件。

du -sh /root/.local/share/Trash/* 2>/dev/null ls -lh /root/.local/share/Trash/files/ | head

这一步非常关键。以我自己的经历为例，有一次训练过程中平台自动保存了一份中间权重到/root目录，因为磁盘满了，被网页端清理脚本移到了回收站，结果我以为它早就被删了，差点把这份权重也一并清掉。所以清空之前，花十几秒扫一眼文件名列表，确认里面没有自己还在用的模型或数据，再执行下一步。

顺带一提，回收站里文件的命名规律往往是原文件名加上一串时间戳后缀，看到一堆类似epoch-60-checkpoint-20250312-*.pt的文件时，大概就是自动保存留下的。

3.2 彻底清理的命令

确认无误后，直接删除回收站里的内容：

rm -rf /root/.local/share/Trash/files/* rm -rf /root/.local/share/Trash/info/*

如果回收站路径是在/root/autodl-tmp下，把路径换成对应的数据盘路径即可。这个操作会直接把文件占用的磁盘block释放掉，df -h里的可用空间会立刻回升。

删除时如果遇到Permission denied，多半是文件属主和当前用户的UID不一致，加sudo重试就行：

sudo rm -rf /root/.local/share/Trash/files/*

这里有一个我踩过的坑：不要顺手把整个Trash目录给删了，只删files和info两个子目录里的内容就够了。目录结构本身要保留，否则网页端文件管理器可能会因为找不到回收站目录而报错，甚至影响平台的自动清理逻辑。

清完之后用df -h再确认一次，顺便看看回收站目录是否已经空了：

df -h /root /root/autodl-tmp du -sh /root/.local/share/Trash

正常情况下，可用空间会明显变大。如果你发现删除大文件之后空间没有立刻释放，别急，下一节会重点讲这个问题。

3.3 网页端“彻底删除”和命令行删除的区别

AutoDL网页端的文件管理器常见两个删除入口：普通删除和彻底删除。两者的行为差异很大，这里直接用表格来区分：

从效率上来讲，命令行rm比网页端彻底删除更适合批量场景。网页端在删除大量文件时经常出现进度条转个没完、页面卡住的情况，而SSH里一条rm -rf下去，几十GB的文件几秒钟就释放了。另外，如果你有定期清理的需求，命令行配合cron脚本也更容易自动化。

3.4 带时间戳的部分清理命令

有时候回收站里有很多文件，但只想清理几天前的旧内容，可以用find配合时间参数精确删除：

find /root/.local/share/Trash/files -mtime +7 -exec rm -rf {} \;

这条命令会删除回收站中7天前被移入的所有文件。注意-mtime +7是按文件的修改时间计算的，回收站里的文件一般在移入时会同步更新mtime，所以基本能对上。使用-exec rm -rf {} \;时一定要先跑一遍不带-exec的find看看命中列表，确认没有需要保留的文件。

4. 常见问题与排查技巧实录

4.1 删了文件但空间纹丝不动

这是我遇到最多的问题，也是最让人崩溃的。删除动作做完，df -h一看，可用空间跟没删之前一模一样。遇到这种情况，排查顺序建议如下：

第一，看删除的是不是网页端普通删除，文件是否进了回收站。如果是，按上面的流程去清回收站，不要重复删可见文件。

第二，检查回收站是不是在另一个挂载点。比如你清理的系统盘回收站，但实际文件是数据盘上的，那自然看不到变化。

第三，确认是否有进程还在持有已被删除文件的句柄。训练脚本如果还在运行，某个被删除的模型文件可能仍在被进程引用，空间只有在进程退出后才会释放。用下面的命令可以找到这些文件：

lsof +L1 | grep deleted

输出里的文件虽然已经显示为deleted，但依然占用着磁盘空间。这种情况最稳妥的办法是等训练进程结束后再判断是否需要重启实例释放空间。

第四，删除操作完成后跑一下sync让文件系统把缓存写回，再查看df -h。如果你是在图形界面里删除的大量文件，系统可能还没完全更新统计信息。

4.2 回收站里的文件无法删除

有时候执行rm -rf会提示权限不足。这是因为回收站文件中可能有部分属于root用户或其他服务用户，当前登录用户UID不一致导致的。用ls -l查看文件属主，再用sudo rm -rf清理即可。

这里要提醒一句：别用sudo rm -rf /root/.local/share/Trash去删整个目录。真这么干了，网页端文件管理可能短暂报错，某些平台组件会在下次使用时重建目录，但已经属于无谓的风险了。只清files和info两个子目录里的内容，行为最安全。

4.3 快速找到占用空间最大的文件

如果回收站已经清干净了，磁盘还是紧张，那得把目光放到正常文件上。找大文件最方便的是du和find配合：

find /root -maxdepth 4 -type f -size +2G -exec ls -lh {} \; 2>/dev/null | sort -k5 -rh | head

这条命令会找出所有大于2GB的文件并排序，一眼就能看出谁在占地方。我一般先跑这个，再决定哪些文件可以清理，而不是漫无目的地用du到处翻。

4.4 误删之后的黄金恢复时间

在回收站还没被清空之前，恢复其实很简单。回收站里的文件本质上只是被移动了位置，找到原始文件名后，把它移回去就行：

mv /root/.local/share/Trash/files/某个文件 /root/要恢复的目录/

注意一个细节：同样的文件如果被删除过两次，回收站里可能会保留带时间戳的副本，恢复后需要手动去掉时间戳后缀。而如果用命令行rm直接删的文件，基本没有后悔药可吃，只能从其他渠道重新下载或生成。

5. 从根源上减少回收站堆积

5.1 文件落盘路径提前规划

说句实在话，清理回收站只是亡羊补牢，更聪明的做法是让大文件压根不往系统盘上放。AutoDL环境里，模型权重和数据集这类大文件应该养成立即放入/root/autodl-tmp的习惯，平时开发的脚本放在/root/code，这两个位置分开管理，系统盘就不容易被意外塞满。

当然，网页端删除数据盘文件时，回收站依然会拦截一次。所以就算文件放在数据盘，删除后也别忘了走一遍回收站清理的流程，只是这时候目标路径是数据盘下的隐藏目录，而不是系统盘那个。

5.2 删除文件前先问自己三个问题

每次打算删除重要文件时，先确认三件事：

• 这个文件还有没有其他副本？
• 训练或调试过程中还会不会用到？
• 删掉之后是否可以快速重新生成？

如果三个问题里有一个答案不确定，就不建议走彻底删除或命令行rm，先把文件挪到回收站过渡几天，确认没关系了再清。这个习惯帮我躲过了一次大坑——训练到一半发现需要用到早先删掉的预处理数据，好在当时没急着清回收站，一个mv就救回来了。

5.3 顺手清理环境缓存，别只盯着回收站

很多人以为磁盘满了都是因为自己的文件太多，但实际环境里，缓存和日志的占用一点都不少。/root/.cache下各类模型下载缓存、pip缓存、conda缓存经常占到十几个G。平时用几条命令就能顺手清理：

pip cache purge conda clean -a rm -rf /root/.cache/*

这里要小心，/root/.cache里如果存着当前进程正在使用的临时文件，直接删可能会有问题；但大多数情况下，这些都是可再生成的缓存数据。至于训练日志目录，比如/root/autodl-tmp/log下的旧日志，也建议定期清理，很多训练脚本跑完并不自动删日志，时间一长堆积量非常可观。

5.4 训练间隙定时巡检

最后分享一个小习惯：每次跑训练任务之前，用三十秒扫一眼存储占用。命令都不用复杂，就两条：

df -h /root /root/autodl-tmp du -sh /root/.local/share/Trash 2>/dev/null

空间不够时提前清理，总比跑到一半报No space left on device要舒服得多。AutoDL这种按量计费的平台，磁盘多占一分钟就是多掏一分钟的钱，别跟自己的预算过不去。

我在实际清理回收站的过程中，最深的一条体会是：别信任任何一层“假删除”。网页端显示删除成功，不代表空间释放了；命令行rm虽然直接，但也意味着没有后悔余地。每次准备清空间时，把文件列表扫一遍、确认回收站路径、再执行清理，这三步操作基本不会出错。真遇到磁盘告急的情况也别慌，先清掉回收站，通常一轮下来就能救回几十GB的可用空间。