系统体检报告

DESKTOP-DGJP6BI · Windows 11 + Ubuntu 24.04 (WSL2) · Ryzen 9 9950X3D · 61.6 GB RAM · RTX 5090 32GB
体检 2026-07-29 15:11 → 修复 2026-07-31 00:36 · 执行方式：Claude 主会话直接取证＋ Codex 两轮独立并行审计（26 min + 33 min），双方交叉验证

86 GB

磁盘空间回收

系统盘 15 GB ＋数据盘 71 GB

已修复问题

每项附验证输出与回滚命令

备份单元建立

24 git 镜像＋ 29 项目快照

抢救的代码仓库

此前只存在于本机

01最要紧的三个发现

按「会不会真的丢东西 / 是不是正在出错」排序，不按修起来难不难。

Tailscale SSH 认证死循环严重 · 正在发生

后台常驻的 mcp-memory-tunnel.sh 陷入无限重连，MCP memory service 完全不可用。

当日重连: 130 次
累计触发认证: 1124 次
隧道端口: 127.0.0.1:8765 — Connection refused
网络层: tailscale ping gpu13 → 6 ms 直连，完全正常

根因不是网络。Tailscale ACL 对该 SSH 规则启用了 check mode（周期性强制浏览器认证），而隧道脚本用 ssh -o BatchMode=yes —— 自动化进程在架构上不可能完成交互式认证，于是每 5 秒重连一次，每轮生成一个新的 login URL。

一个根因，两处症状。同一条 ACL 规则同时导致：① MCP memory 隧道刷屏 1124 次；② bbhouse 备份 7/28 少了一行 gpu13 ok。后者安静得几乎不可能被人发现 —— 这正是备份必须有主动告警、而不能靠人读日志的原因。

数据盘挂载竞态，且失败被静默吞掉已修复

体检开始时 /mnt/data（2 TB，339 GB 数据）根本没有挂载，而 Windows 计划任务报告 LastTaskResult: 0（成功）。

根因链：--bare attach 之后立刻执行 mount LABEL=aidata，但块设备枚举与 label 注册需要数秒 → mount 失败 → 失败被 || 短路吞掉 → bash -lc 的退出码取自末尾的 chown（总是成功）→ 任务永远报成功，磁盘永远没挂上。

修复：轮询等待 label 就绪（最多 20 s）＋失败时真的返回非 0 ＋写审计日志。验证时任务写出了 MOUNT_OK。

万幸挂载点目录只有 4.0 K —— 没有数据被误写到未挂载的挂载点上，这是这类故障里最危险的场景。

32 个项目没有任何可验证备份已建立备份体系

Codex 第二轮的核心发现，与主会话的排查互相印证：

/mnt/data/projects 43 个项目中 32 个无独立备份
ComfyUI 的 models/（61.9 GB）被 .gitignore 排除，Git 完全不保护
15 个 Cloudflare Pages 项目只有 2 个有 git 集成
13 个 repo 有未 push 或无 remote 的工作（ai-daoshi ahead 6、storeysg ahead 9、ghosthand dirty 18…）
Syncthing 的 ~/Claude Config 路径已不存在，两个 folder 都无 versioning —— 误删会同步传播到所有节点
无快照、无回收站：/.snapshots、~/.local/share/Trash、/mnt/data/.Trash* 全部不存在，删除操作没有任何后悔窗口

清理磁盘不解决这个。真丢数据是从这儿丢的。

02空间回收 86 GB

按回收量排序。每一项都在删除前做了引用检查，去重则用 hardlink 而非删除。

重复模型去重

39 GB

死 swapfile

32 GB

历史 audit 产物

11 GB

pip 中断残留

3.8 GB

journald 死数据

0.5 GB

条长按回收量比例绘制 · 合计 86.3 GB

盘	体检开始	现在	回收	使用率
`/` 系统盘	331 GB	316 GB	15 GB	34%
`/mnt/data` 数据盘	339 GB	268 GB	71 GB	14%

去重那步刻意没有删除任何一份：用 ln B A.hltmp && mv -f A.hltmp A 把两份合并成 hardlink —— 两个路径都保留、所有引用不受影响、内容零变化，中断也不丢文件。合并后重新计算 SHA-256 确认与合并前一致。

删一份要先搞清楚哪个路径被谁引用（ComfyUI 配置、workflow JSON、脚本里的绝对路径都可能指向任一份），判断错了就是坏引用。hardlink 把「回收空间」和「保留路径」解耦。代价是共享写语义，所以只适合模型这类只读资产。

03已修复清单

#	项目	验证方式
1	DNS 顺序：去掉 `rotate`，最快的排前面	4 个关键域名解析正常，6 ms
2	`mount-ai.cmd` 挂载竞态：轮询重试＋失败真返回非 0	任务返回 0，日志写出 `MOUNT_OK`
3	9 个 `.env`/`.npmrc` 权限 → 600	逐个 `stat` 确认
4	凭据泄漏排查	git 侧干净：`.gitignore:31` 有 `**/.env`，历史 0 命中
5	清理 8 个 pip 解包残留	回收 3.8 GB
6	清理 journald 死数据	先确认最后记录停在 5/6 且无进程，531 M → 4 K
7	清理 5 个失效 symlink	顶层断链 5 → 0
8	wrangler 4.82.2 → 4.115.0	版本号确认
9	6 组重复模型 hardlink 合并	合并后重算 SHA-256 与合并前一致
10	删除 32 GB 死 swapfile	五重确认：swapon / /proc/swaps / 全配置搜索 / lsof / allocated blocks
11	删除 11 GB 历史 audit 产物	删前查看内容并确认别处无副本
12	9 个代码仓库抢救推送	逐个 `ahead` 归零
13	本地备份体系（53 个单元）	逐个校验文件数＋总字节＋ HEAD

04代码仓库抢救

动手之前先挖出了一个长期隐患 —— 这个比抢救本身更重要。

默认 SSH key 是 deploy key，不是账号 key长期隐患

$ ssh -T [email protected]
Hi shuaige121/claude-configs! You've successfully authenticated...

返回 Hi <user>/<repo>! 而非 Hi <user>! —— 这是 deploy key 的标志，只绑定 claude-configs 一个仓库，对其它任何仓库都没有写权限。这一条解释了三个迷惑现象：

现象	真相
`storeysg` 报 "Repository not found"	仓库存在且是 PRIVATE（7/28 刚推过）。GitHub 对无权访问的 private repo 统一报 404 而非 403，避免泄露"这个仓库存在"
`zhouruby.com` 能读却不能写	它是 PUBLIC repo，读谁都行，写需要权限
`gh repo create --push` 建出空仓库	gh 给 remote 设的是 SSH URL，push 立刻被 deploy key 拦掉

有效凭据是 gh token（scopes: repo），因此全程改走 HTTPS。

仓库	动作	结果
`~/storeysg`	推 9 commits	ahead 0
`~/leonardchow-work/zhouruby.com`	推 1 commit	ahead 0
`~/.claude`	提交 14 文件＋推送	untracked 归零
`DATA/vlab`	新建 private repo ＋推 16 commits	ahead 0
`~/ascend-sg`	新建 private repo ＋推 9 commits	ahead 0
`~/zhouruby-portfolio`	新建 private repo ＋推 2 commits	ahead 0
`~/ghosthand`	新建 private repo ＋推 1 commit	历史已保护
`DATA/maple-selector`	新建 private repo ＋推 15 commits	历史已保护
`DATA/roomforge`	无需推送	本地是过期副本，落后远端 53 个 commit

推送前每个仓库都过了凭据门禁（检查被 git 跟踪的文件＋ git 历史）。命中的 4 个文件全部人工判定为非 secret：.npmrc 只有 legacy-peer-deps=true；.env.example 里是 URL 和 Cloudflare ID（wrangler whoami 本来就明文输出 Account ID）。zhouruby.com 是 PUBLIC repo，额外审了那 175 行新增：无密钥前缀、无 password/secret 赋值，3 个长串都是 CSS class。

05本地备份体系

不依赖 GitHub。备份盘与源数据物理隔离。

磁盘	型号	盘符	角色
#0	Samsung 9100 PRO 1TB	C: D:	系统
#1	Samsung 990 PRO 4TB	E:	源数据（`ai.vhdx` → `/mnt/data`）
#2	Samsung 990 PRO 4TB	F:	备份目标（1.2 T 可用）

git 完整镜像

521 MB · commit 数与 HEAD 双重校验

非 git 项目快照

17 GB · 文件数与总字节校验

校验失败

53 个单元全部一致

过程中撞到的坑：NTFS 大小写不敏感会静默丢文件已规避

首次 rsync 后校验发现 sg-ea-research 少了 3 个文件（源 2490 / 备 2487）。定位后确认根因是备份盘 F: 为 NTFS，经 DrvFS 挂载后文件名大小写不敏感：

sci_gebiz_ds_q_SCIENTEC.json   ↔  sci_gebiz_ds_q_ScienTec.json
..._EA_REG_ID_R1981125.txt      ↔  ..._EA_Reg_ID_R1981125.txt
..._MOM_LICENSE_NO_16C7994_.txt ↔  ..._MOM_License_No_16C7994_.txt

3 组冲突精确对应 3 个缺失文件。同目录下只差大小写的两个文件被折叠成一个 —— 而 rsync 退出码是 0。

解决：对存在冲突的项目改用 tar.zst 归档（tar 内部保留原始文件名，不受文件系统限制）。826 MB → 184 MB，2490 文件全部保留，6 个冲突文件逐一验证在档。这个检测逻辑已写进备份脚本，自动分流。

脚本	频率	内容
`backup-git-mirrors.sh`	每天 04:30	24 个 repo `push --mirror`，含分支与 tag
`backup-projects-rsync.sh`	每天 05:00	29 个非 git 项目；自动检测大小写冲突并分流 rsync / tar

两个脚本都遵循同一条原则：备份盘不可用时立刻失败退出，绝不把「盘没挂上」静默当成「没有文件要备份」 —— 这次体检里发现的备份类问题，几乎全部源于静默失败。

06其它值得记的发现

两处我先报错、又自己证伪的虚警

PCIe 不是降级。看到 Gen 2 / max 5 差点报故障，跑真实 CUDA 负载后：

空闲: Gen 2, P3, 1192 MHz,  68 W
负载: Gen 5, P1, 2512 MHz, 595 W, 98% 利用率

Gen 2 是空闲省电，满载跑满 Gen 5，600 W 功耗墙也吃满。凡是带「当前值」的指标，都要先问一句「当前处于什么状态」。

Cloudflare 那个 401 是端点选错。Account API Token 本来就查不了 /user/tokens/verify，换 /accounts/{id}/tokens/verify 是 200，R2 bucket 也能正常列出。

配置漂移：文档写着能用，实际早就断了待处理

portproxy 规则表为空，RefreshWSLPortproxy 计划任务已不存在 → LAN 进 WSL 的 2222 端口完全不通（四条独立路径验证）
记录中「本机双 IP .13/.6」已不符 —— Wi-Fi 网卡处于 Disconnected，实际只有 10G 有线在用
journald 自 2026-05-06 起就没在工作（最后一条是 Journal stopped）。所以「journalctl 查不到今天的错误」不等于「今天没错误」
DNS 把最慢的 1.1.1.1（37.6 ms）放在第一位还开了 rotate，而 8.8.8.8 只要 2.2 ms — 约一半查询白白多花 35 ms（已修）

服务集成盘点3 项待配

服务	状态
1Password	正常 CLI 2.34.0 已登录
Cloudflare	正常 token 有效，R2 可列
MCP servers	4 个中 3 个正常；`memory` 因隧道故障不可用
Gmail	未配置缺 app password，daily-ingest 每天跳过
Notion	零集成无 MCP、无 API key、无 CLI
显示器	未跑满 XG32UCWG 当前 2560×1440@120Hz，驱动报最高 164Hz，EDID 原生 3840×2160

07待办

优先级	事项	为什么需要你
高	Tailscale ACL：SSH 规则 `"check"` → `"accept"`	一改修两个故障，需在浏览器操作
高	重建 portproxy ＋ `RefreshWSLPortproxy` 任务	需管理员权限
中	`gh auth refresh -s workflow`	3 个 repo 卡在此（含 `.github/workflows/`），需浏览器授权
中	`Optimize-VHD` compact `ai.vhdx`	可回收约 412 GB，需 `wsl --shutdown`
低	2 把 SSH 私钥加 passphrase	需交互输入；7 个 alias 开着 ForwardAgent，含 2 个 root 登录
低	22 个未提交文件＋ 8 个 auto-stash	需逐个看 diff 决定，已提交历史都已有异地副本

08双方分工

Codex 跑在 bwrap --unshare-pid --unshare-net --dev /dev 沙箱里，看不到宿主进程、网络和 GPU —— 它在报告里诚实标注了这些盲区，两边正好互补。

来源	独有贡献
主会话	宿主进程与服务、Docker、监听端口、GPU 实时状态、Windows 侧信息、cron 日志审计、git 状态、Tailscale SSH 故障、portproxy、显示器与驱动、网络连通性
Codex	SRSO 漏洞硬证据、36 GiB 重复模型（SHA-256 ＋ inode ＋ link count 三重验证）、`uv cache` 精确可回收量、32 GB 死 swapfile、ext4 错误计数器、无备份项目清单、敏感文件权限面、SSH 私钥无 passphrase
双方一致	`/mnt/wsl` 无 RAM 泄漏、磁盘/inode/内存/CPU 正常、`/tmp` 29 G、52 个待更新包、E 盘 81%

分歧一处：Codex 把 SRSO 推测执行漏洞列为唯一「严重」，主会话下调为「关注」—— Safe RET 缓解已生效，缺的 microcode 只能靠宿主 BIOS，且单用户物理开发机的威胁模型不匹配。Codex 的取证是对的（主会话最初把那条 dmesg 当成 WSL 正常噪声忽略了），分级按威胁模型调整。

报告生成于 2026-07-31 · 所有数值均来自实际执行的命令输出，未经估算或推断
完整取证记录与回滚命令见 health-check-20260729.md / repair-log-20260729.md