L40S 集群回收 · 2026-09-28
L40S 数据备份清单
L40S 节点原定 2026-09-28 14:00 UTC（加州时间 7:00）回收，实际 11:04 UTC 左右就断开了。断开前，EFS 上的共享数据（/mnt/efs/monitor）和各节点本地盘上不可再生的结果都已拷到 pod 的 juicefs，并逐文件用校验和核对过。下面列出每一块数据原来在哪、现在在哪、多大、核对结果，以及故意没拷的内容和原因。
EFS 备份（本会话）
1,576.9 GB
801,088 个文件，其中录像 171,151 段
EFS 核对
241/241 块
全部通过全量校验和（rsync -c）。此前修复被 juicefs 写坏的文件约 1,400 个，最终校验时又重传 3 个
节点本地盘备份（robodojo评测）
35.6 GB
69,296 个文件，43 项，全部校验和通过
可能丢失
1 个 checkpoint
dowam_skill_step_032500_ema（见下）
路径怎么找：EFS 上的
/mnt/efs/monitor/X 现在在 /workspace/l40s_efs_backup_20260928/efs/monitor/X；节点本地盘 l40s-east2-N:/opt/dlami/nvme/... 在 /workspace/l40s_nvme_backup_20260928/nodeNN/...。拷贝进度日志：/workspace/l40s_efs_backup_20260928/progress.log。拷贝时遇到的 juicefs 问题（已修复）：往 juicefs 写入时约 0.1–0.3% 的文件悄悄丢了内容——有的变成 0 字节，有的大小和修改时间都对但内容全是 0，rsync 默认的比对查不出来。处理办法：先对所有已拷数据按大小重传一遍，再用
rsync -c 逐文件比对校验和、对不上就重传，循环到一遍下来没有需要重传的文件为止；最后扫描所有文件，确认没有开头全是 0 的文件（STL 网格文件开头本来就是 0，已排除），并抽查 345 个文件的 md5。以后往 juicefs 大批量拷数据，都要用校验和核对。可能丢失：
/mnt/efs/monitor/ckpts/dowam_skill_step_032500_ema（57 GB）。它不是从 pod 上的训练目录导出的，而是 09-22 从 Fang 的只读评测包 robodojo_eval_v1/checkpoints/step_032500_ema.pt 复制到 EFS 的；这份文件原本在每个节点的 /opt/dlami/nvme/monitor/robodojo_eval_v1/checkpoints/ 和 ckpt_cache 里都有，但备份时被当成可重建的评测环境跳过了。juicefs 上找不到它的原件：robodojo_skill 各训练目录只保留 1 万步整数倍的权重。最可能的来源是 ziming 的训练 robodojo_skill_100k_gbs256_noac_compile_r4000_16n_h100_20260920T065327Z 在 09-20 的第 3.25 万步。需要的话请问 Fang（评测包的制作者，包可能在 exx/199 那台机器上）或 ziming（这次训练的负责人）。不是我们的数据，没有拷：5–8 号机本地盘上 songyao（约 270–340 GB）、alienware（约 330–440 GB）、hengyu（约 30 GB）的目录。节点回收后这些已经拿不到了，需要的话请本人确认是否另有备份。
EFS 共享数据
没有拷的 checkpoint（原件已在 juicefs 上）
EFS 上的这些只是训练权重导出的 bf16 副本，原件（fp32 训练权重或导出文件）已在 juicefs 上，需要时可用 export_ema_bf16.py 重新导出。
| EFS 上的副本 | juicefs 上的原件 |
|---|
节点本地盘（robodojo评测 负责）
节点本地盘上绝大多数是可重建的评测环境和缓存，不可再生的结果本来就写在 EFS 上。下面是另外拷下来的内容，清单来自 /workspace/l40s_nvme_backup_20260928/INVENTORY.json。
| 节点 | 原路径 → 备份路径 | 内容 | 文件数 | 大小 | 核对 |
|---|