Store 垃圾回收与存储优化：gc root、去重与瘦身

① 内容寻址：路径由输入哈希决定，输入变一点就是一个全新路径，旧路径原地不动
② 引用闭包：保留一个路径往往连带保留它的整条运行时闭包（可能是几百个路径）
③ 多层根：系统 profile、用户 profile、项目目录里的 result 符号链接，各留一份
典型曲线：首次安装数 GB；每次 nixos-rebuild switch 再 +1~3 GB（新闭包 + 旧世代）；
          每次开发构建数百 MB；长期不回收则累积到数百 GB。

/nix/store 下的路径是共享的：同一个库可能被几十个包同时引用，
直接 rm -rf 会让其他包的运行环境瞬间损坏，
而且 store 的元数据库不知道你删了东西，后续操作会出现不一致。
正确做法只有一个：让路径变成"不可达"，再交给 GC 统一删除。

GC 算法（概念版）：
  ① 枚举所有 gc root
  ② 从每个根出发，沿 .drv 与产物的引用关系做图遍历
  ③ 可达集合 = 保留；不可达集合 = 死路径，可删除
因此："没人用"是主观判断，"不可达"才是客观事实。

nix-store --gc --print-roots        # 列出所有根（含类型与目标）
nix-store --gc --print-dead | head  # 只看将被删除的死路径
nix-store --gc --print-live | wc -l # 统计活路径数量

① 运行中进程也是根：GC 会扫描 /proc，正在运行的服务所引用的路径不会被删；
   但存在竞态——进程启动前路径被删就会启动失败，生产机回收应安排在维护窗口。
② 间接根的残留：删掉项目里的 result 之后仍可能"删不掉"，
   因为 gcroots/auto 里还有一条指向它的登记，需要先清掉登记。

nix-collect-garbage          # 老命令
nix store gc                 # 新命令，等价
nix store gc --dry-run       # 先看会删什么
nix-store --gc --print-dead | wc -l   # 死路径条数

nix-collect-garbage --delete-older-than 30d   # 按时间回收
nix-collect-garbage --max-freed 20G           # 限量回收

nix store delete /nix/store/<hash>-<name>              # 仍被引用时会拒绝删除
nix-store --query --referrers /nix/store/<hash>-<name> # 查谁在引用它

常见原因：
  ① 只删了 result 链接，没删 profile 里的世代 → 世代仍是根
  ② 世代删了但 auto 登记还在 → 仍是间接根
  ③ 服务正在运行 → /proc 让它仍是根
  ④ 删除的是硬链接去重后的路径，磁盘并未真正释放（见第 5 节）

# NixOS：每周回收一次，删除 30 天前的世代
nix.gc = {
  automatic = true;
  dates = "weekly";
  options = "--delete-older-than 30d";
};

# 空闲空间低于 min-free 时自动触发 GC，直到达到 max-free
nix.settings.min-free = 5 * 1024 * 1024 * 1024;      # 5 GiB
nix.settings.max-free = 20 * 1024 * 1024 * 1024;     # 20 GiB

这两个值的作用是"防爆盘"：低于 min-free 时守护进程主动回收，
回收直到空闲达到 max-free 为止。与定时 GC 互补：定时管日常，min-free 管突发。
注意：min-free 触发的是回收，不保证能腾出足够空间（死路径本来就少时会失败）。

systemctl list-timers | grep nix-gc
systemctl status nix-gc.service --no-pager
journalctl -u nix-gc.service -n 30 --no-pager
df -h /nix

同一个文件出现在多个 store 路径里的情况非常普遍：
每个新世代都包含一份几乎相同的闭包，多个包也各自带一份相同的许可证文本与图标。
这些文件内容相同但路径不同，逻辑上占两份磁盘。

nix.settings.auto-optimise-store = true;   # NixOS：每次构建后自动去重

nix store optimise                          # 手动对已有 store 做一次全量去重
du -sh --apparent-size /nix/store           # 逻辑大小
du -sh /nix/store                           # 实际占用（差值即去重节省）

代价：
  - 每次构建后多一次全 store 扫描，构建密集的机器上 IO 明显增加
  - 文件系统必须支持硬链接（部分网络文件系统不支持，会导致失败）
风险：
  - 去重后的路径相互耦合，删除其中一个只减少链接计数，磁盘不一定释放
  - 若怀疑 store 被外部修改，用 nix store verify --all 校验、nix store repair 修复
建议：
  - 长期运行、世代保留较多的机器开启（收益通常 20%~40%）
  - 一次性构建容器可以不开启；先量化差值再决定

nix path-info -Sh /run/current-system                      # 当前系统闭包大小
nix path-info -Sh --recursive /run/current-system | sort -k2 -h | tail -20
nix path-info -S --json /run/current-system \
  | jq -r 'to_entries[] | "\(.value.narSize)\t\(.key)"' | sort -n | tail

nix-tree /run/current-system   # 交互式浏览引用图：谁依赖谁、谁占多大
nix-du -s=500MB | dot -Tpng > store.png   # 可选：生成占用树图

① df -h /nix                          → 总量与增长趋势
② nix path-info -Sh /run/current-system → 当前系统闭包有多大
③ nix-tree /run/current-system        → 谁是大头、为什么被保留
④ nix store gc --dry-run              → 回收能释放多少
⑤ du -sh vs du -sh --apparent-size    → 去重还能省多少

# 默认 keep-derivations = true、keep-outputs = false
nix.settings.keep-derivations = false;
nix.settings.keep-outputs = false;

含义：keep-derivations 决定是否保留 .drv 作为根的传播；
      keep-outputs 决定是否保留构建输入的输出版本。
这两个开关影响"为了能重新构建而保留多少"：关掉后 store 更小，
但重建时需要重新下载或重建部分依赖。

nix build .#mypkg --no-out-link      # 不创建 result 符号链接（用完即弃）
nix shell nixpkgs#jq -c jq --version # nix shell / nix run 不注册长期根

注意：--no-out-link 得到的路径没有根，下次 GC 就会被回收，
      因此只适合"用完即弃"的验证，不适合需要保留的产物。

不该放进 store 的内容：数据集、模型权重、虚拟机镜像、日志归档。
代价：每次变更都新增一份完整副本，且无法增量存储。
替代：放在普通目录（如 /srv/data）在配置里只引用路径；
      需要版本化时用独立的制品库，而不是 store。

nix-env --list-generations --profile /nix/var/nix/profiles/system
nix-env --delete-generations +5 --profile /nix/var/nix/profiles/system   # 留最近 5 个
nix-env --delete-generations 30d --profile /nix/var/nix/profiles/system  # 删 30 天前
nix-env --list-generations && nix-env --delete-generations +3           # 用户 profile
home-manager expire-generations "-30 days"                               # Home Manager

删除世代只是去掉 gc root，磁盘释放要等后续 GC；
因此"删世代 + 回收"要成对执行（`-d` 参数就是替你做了这两步）。

boot.loader.systemd-boot.configurationLimit = 10;
boot.loader.grub.configurationLimit = 10;

禁止：rm -rf /nix/store/xxx
原因：破坏共享 inode 与元数据库一致性，可能导致大量包损坏
正确：nix store delete（会检查引用）或交给 GC

nix store verify --all                        # 校验所有路径的内容哈希（耗时）
nix store repair /nix/store/<hash>-<name>     # 从缓存重新拉取或重建
nix-store --verify --check-contents --repair  # 全量校验并修复

并发风险：GC 删除某路径时，脚本恰好要启动它 → 报 No such file or directory。
  缓解：生产机在维护窗口回收或先停服务；用 --max-freed 限制单次时长。
共享 store（网络文件系统或 SSH store）：
  GC 必须只在"拥有该 store 的机器"上运行，客户端只做构建与使用；
  否则会删掉别人正在用的路径。定时 GC 只配在 store 主机上。

nix-env --delete-generations +2 --profile /nix/var/nix/profiles/system
nix-collect-garbage --max-freed 20G
nix-tree /run/current-system                        # 找出大闭包
du -sh /nix/store/* 2>/dev/null | sort -h | tail -20