存储空间已回收，stateless_tool 进程还在跑？这是正常现象别动它
痛点场景
做了一次备份大扫除：手动删了几个过期任务，保留策略也清理掉一批旧版本。日志里已经出现「Storage space was successfully reclaimed（存储空间已成功回收）」，备份任务也都没在跑。可打开进程列表一看，一个叫 stateless_tool reclaimextent 的进程还在不知疲倦地跑着，CPU 有动静，存储空间却迟迟不见完全回来。不少管理员的第一反应是：任务卡死了？要不要重启？
答案恰恰相反：这是正常现象，别动它。
这个进程在干什么
Active Backup for Business 对存储的管理分"账面"和"实际"两层。旧备份数据被删除或被保留策略移除后，ABB 会先在账面上回收这些不再使用的数据块，写入「回收成功」日志。但被释放的空间要真正回到 Btrfs 文件系统、反映为可用容量，还需要最后一步：由 stateless_tool reclaimextent 进程在后台把空间返还给文件系统，等文件系统完成可用存储空间的更新后，它会自动停止。
换句话说，日志里的"已回收"代表删除动作完成，而这个进程负责的是"还地"。数据量大的时候，这个收尾阶段跑上一段时间很正常，并不代表任务卡住或备份出错。
判断是否正常
同时满足以下三条，即可放心等待：
- 日志中已出现存储空间成功回收的记录；
- 当前没有任何备份任务在运行；
- 进程占用资源平稳，NAS 整体响应正常。
千万别做的事
不要手动结束该进程，也不要为此重启 NAS。中断它不会损坏数据，但会把可用存储空间的报告时间拖得更久——你等半天的空间，反而要等更久。正确做法就是让它跑完，自然会退出。
验证
过一段时间回到存储空间页面刷新，或对比共享文件夹的可用容量，确认数字逐步回升；再查进程列表，确认 stateless_tool reclaimextent 已经消失。两项都对上，说明整个回收流程真正闭环了。
预防建议
大规模清理备份前，尽量安排在业务低峰期（比如夜间），给后台清理留出充足的运行窗口；保留策略建议小步调整，避免一次性触发海量数据回收。日常巡检时把"清理后空间延迟释放"写进已知现象清单，省得下次同事看到进程又紧张一遍。
如果贵单位正在规划群晖企业级 NAS 的备份体系与容量策略，欢迎参考群晖企业级 NAS 产品，或与我们联系获取针对性建议。