sergio/takana

1#!/usr/bin/env bash
2# store-gc.sh — recolector de basura del store content-addressed. `hammer gc` no existe; esto es.
3#
4# ── EL PROBLEMA QUE RESUELVE ────────────────────────────────────────────────────────────────────
5# El store acumula un artefacto por cada SELLADO, no uno por receta. Cuando una dep cambia, el
6# ArtifactHash de todo lo que cuelga de ella cambia, y el sellado nuevo se suma al viejo en vez de
7# reemplazarlo. Medido el 2026-08-05: 1996 artefactos para 1130 recetas — 12 copias de
8# `libqalculate`, 9 de `qt6-qtdeclarative`, 8 de `gtk4`. 51G de los 74G eran versiones anteriores.
9#
10# ── EL CRITERIO, Y POR QUÉ TIENE DOS ESCALONES ──────────────────────────────────────────────────
11# El conjunto VIVO es `hammer hash` sobre TODAS las recetas de TODAS las colas: es la respuesta a
12# «¿cuál es el hash vigente de esta receta HOY?», que el store solo no puede dar. Lo que no está en
13# ese conjunto es RANCIO — pero rancio se parte en dos cosas muy distintas:
14#
15#   SUPERADO — su nombre de receta TIENE un artefacto vigente presente en el store. Es una versión
16#              anterior de algo que ya está sellado al día. Borrarlo no pierde nada: si hiciera
17#              falta, se reconstruye desde la receta, que está en git.
18#
19#   HUÉRFANO — ningún artefacto con ese nombre es el hash vigente. O sea que el hash de HOY no está
20#              sellado y éste es el ÚNICO ejemplar que existe. Borrarlo sí pierde: es la diferencia
21#              entre «reconstruible en 2 minutos» y «hay que rehacer la torre». En la medición del
22#              2026-08-05 eran 255 artefactos (17G) y casi todos KDE (`kio`×8, `kparts`×8,
23#              `kcmutils`×8) — o sea que las recetas KDE se movieron después del último sellado y el
24#              escritorio hidratado vive de artefactos que ya no son vigentes.
25#
26# Por eso el default borra SÓLO los superados. `--huerfanos` existe para cuando lo que se quiera sea
27# exactamente eso, y hay que quererlo a propósito.
28#
29# ⚠ EL ESPACIO NO SIEMPRE SE LIBERA. Los rootfs hidratados (`work/*-rootfs`) son HARDLINKS al store.
30# Borrar el directorio del store no rompe el rootfs —los datos siguen vivos por el otro enlace— pero
31# tampoco libera el bloque hasta que el rootfs también se vaya. Es una propiedad, no un fallo.
32#
33# ⚠ NO BARRE `store-rust/` NI `store-kern/`: son stores aparte (frentes selfhost y kernel) con sus
34# propias recetas. Sus `.hammer` son manifiestos de artefacto, no recetas de entrada.
35#
36# Uso:   scripts/store-gc.sh [--aplicar] [--huerfanos]
37#        (sin --aplicar es un DRY-RUN: mide y no borra)
38# Env:   STORE (def ./store)   HAMMER (def ./target/release/hammer)   JOBS (def 8)
39set -uo pipefail
40ROOT="$(cd "$(dirname "$0")/.." && pwd)"; cd "$ROOT"
41STORE="${STORE:-./store}"; HAMMER="${HAMMER:-./target/release/hammer}"; JOBS="${JOBS:-8}"
42APLICAR=0; HUERFANOS=0
43for a in "$@"; do
44  case "$a" in
45    --aplicar) APLICAR=1 ;;
46    --huerfanos) HUERFANOS=1 ;;
47    *) echo "opción desconocida: $a" >&2; exit 2 ;;
48  esac
49done
50
51TMP=$(mktemp -d); trap 'rm -rf "$TMP"' EXIT
52
53# ── 1. el conjunto VIVO ─────────────────────────────────────────────────────────────────────────
54# Todas las colas, más las recetas puestas en escena en `tandas/`. Las de tandas suelen no resolver
55# sus deps (la resolución es hermano→padre y viven fuera de `recipes/`) y su hash falla; se incluyen
56# igual porque las que SÍ resuelven son vivas de pleno derecho y omitirlas las volvería rancias.
57{ ls recipes/*.toml recipes/incoming-*/*.toml 2>/dev/null
58  find tandas -name '*.toml' 2>/dev/null | xargs grep -l '^\[source\]' 2>/dev/null
59} | sort -u > "$TMP/recetas.txt"
60echo "==> recetas barridas: $(wc -l < "$TMP/recetas.txt")"
61
62xargs -P "$JOBS" -I{} sh -c "$HAMMER --store $STORE hash \"{}\" 2>/dev/null | tail -1" < "$TMP/recetas.txt" \
63  | grep '^b3:' | sed 's/^b3://' | sort -u > "$TMP/vivos.txt"
64echo "    hashes vigentes calculables: $(wc -l < "$TMP/vivos.txt")"
65
66# Cuántas NO dieron hash. No es fatal (ver arriba) pero es el número que dice cuánta confianza tiene
67# la clasificación: si sube mucho, algo se rompió en la resolución de deps y NO hay que borrar.
68FALLOS=$(( $(wc -l < "$TMP/recetas.txt") - $(
69  xargs -P "$JOBS" -I{} sh -c "$HAMMER --store $STORE hash \"{}\" >/dev/null 2>&1 && echo ok" < "$TMP/recetas.txt" | wc -l) ))
70echo "    recetas cuyo hash FALLA: $FALLOS"
71
72# ── 2. clasificar el store ──────────────────────────────────────────────────────────────────────
73ls "$STORE" | grep -E '^[0-9a-f]{64}-' > "$TMP/dirs.txt"
74python3 - "$TMP" <<'PY'
75import sys, os
76t = sys.argv[1]
77vivos = set(open(f"{t}/vivos.txt").read().split())
78dirs = [l.strip() for l in open(f"{t}/dirs.txt") if l.strip()]
79part = lambda d: (d.split('-', 1)[0], d.split('-', 1)[1])
80nombres_vivos = {n for h, n in map(part, dirs) if h in vivos}
81sup, hue, viv = [], [], []
82for d in dirs:
83    h, n = part(d)
84    (viv if h in vivos else (sup if n in nombres_vivos else hue)).append(d)
85for f, xs in (("vigentes", viv), ("superados", sup), ("huerfanos", hue)):
86    open(f"{t}/{f}.txt", "w").write("".join(x + "\n" for x in xs))
87print(f"    artefactos: {len(dirs)} · vigentes {len(viv)} · superados {len(sup)} · huérfanos {len(hue)}")
88PY
89
90espacio() {  # du sobre una lista de dirs, tolerante a lista vacía
91  [ -s "$1" ] || { echo "0"; return; }
92  sed "s|^|$STORE/|" "$1" | tr '\n' '\0' | du -sch --files0-from=- 2>/dev/null | tail -1 | cut -f1
93}
94echo "==> espacio: superados $(espacio "$TMP/superados.txt") · huérfanos $(espacio "$TMP/huerfanos.txt")"
95
96# ── 3. borrar ───────────────────────────────────────────────────────────────────────────────────
97OBJETIVO="$TMP/superados.txt"
98if [ "$HUERFANOS" = 1 ]; then
99  cat "$TMP/superados.txt" "$TMP/huerfanos.txt" > "$TMP/objetivo.txt"; OBJETIVO="$TMP/objetivo.txt"
100  echo "!!  --huerfanos: se borran TAMBIÉN los únicos ejemplares de su receta"
101fi
102
103if [ "$APLICAR" != 1 ]; then
104  echo "==> DRY-RUN: no se borró nada. Repetí con --aplicar."
105  exit 0
106fi
107
108MANIFIESTO="work/store-gc-$(date +%Y-%m-%dT%H%M%S).txt"
109mkdir -p work; cp "$OBJETIVO" "$MANIFIESTO"
110echo "==> manifiesto de lo borrado: $MANIFIESTO"
111ANTES=$(df -h /home 2>/dev/null | tail -1 | awk '{print $4}')
112sed "s|^|$STORE/|" "$OBJETIVO" | xargs rm -rf
113
114# ── GUARDIÁN: NO reportar «borrado» sin comprobarlo ─────────────────────────────────────────────
115# 2026-08-07: este script informó «364 artefactos borrados · libres: 24G → 48G» y NO había borrado
116# NINGUNO — los 364 del manifiesto seguían enteros en el store, y los 24G que se liberaron esa vez
117# vinieron de otro lado. `xargs rm -rf` salió con 0 y el `echo` de abajo se lo creyó. (Se reprodujo:
118# corriendo el script en SEGUNDO PLANO el borrado no se materializa; en primer plano sí. Da igual la
119# causa: un `rm` que devuelve 0 no es prueba de que el fichero se fue.)
120#
121# Consecuencia real: la válvula de escape del disco estaba rota EN SILENCIO, y encima reportaba éxito,
122# que es peor que fallar. El disco llegó al 98%.
123#
124# Por eso ahora se RECUENTA sobre el filesystem y el script sale distinto de cero si sobrevivió algo.
125QUEDAN=0
126while IFS= read -r l; do [ -e "$STORE/$l" ] && QUEDAN=$((QUEDAN+1)); done < "$OBJETIVO"
127PEDIDOS=$(wc -l < "$OBJETIVO")
128AHORA=$(df -h /home 2>/dev/null | tail -1 | awk '{print $4}')
129if [ "$QUEDAN" -gt 0 ]; then
130  echo "!!  BORRADO INCOMPLETO: $QUEDAN de $PEDIDOS artefactos SIGUEN en $STORE."
131  echo "!!  No te fíes del espacio libre de abajo. Reintentá en PRIMER PLANO y volvé a verificar."
132  echo "==> libres: $ANTES → $AHORA"
133  exit 1
134fi
135# ── REGISTRO ACUMULADO, para que lo podado NO VUELVA ───────────────────────────────────────────
136# 2026-08-07: se podaron 362 artefactos (24 G) por la mañana y por la tarde volvieron a aparecer LOS
137# MISMOS 362 — solapamiento del 100%. La causa no estaba acá sino en `farm/farm-sync.sh`, que bajaba
138# el store del worker entero; el worker no se poda, así que nos devolvía lo borrado en cada cosecha.
139# Podar → cosechar → vuelven. Este registro es la memoria que le faltaba al sistema: `farm-sync` lo
140# usa como `--exclude-from`. Sin él, el gc es una rueda de hámster que informa éxito cada vez.
141# ⚠ RUTA ABSOLUTA Y `touch` PREVIO. El 2026-08-21 esta línea murió con
142# «work/store-gc-superados.txt: No such file or directory» DESPUÉS de haber borrado ya los 256
143# artefactos — o sea que la poda ocurrió y su registro NO se escribió, que es la combinación exacta
144# que reabre el bucle churn: `farm-sync` no tiene qué excluir y la cosecha los devuelve. El script
145# hace `cd "$ROOT"` al arrancar, así que la ruta relativa DEBERÍA valer; que fallara igual es razón
146# de sobra para no depender de ello en el paso que evita repetir el trabajo de una tanda entera.
147LEDGER="$ROOT/work/store-gc-superados.txt"
148mkdir -p "$ROOT/work" && touch "$LEDGER"
149if cat "$OBJETIVO" "$LEDGER" 2>/dev/null | sort -u > "$LEDGER.tmp" && mv "$LEDGER.tmp" "$LEDGER"; then
150  echo "==> registro acumulado: $(wc -l < "$LEDGER") artefactos que NO deben volver ($LEDGER)"
151else
152  # Ruidoso a propósito: sin ledger la poda es una rueda de hámster que informa éxito cada vez.
153  echo "!!  NO pude escribir el registro $LEDGER — los $PEDIDOS borrados VOLVERÁN en la próxima" >&2
154  echo "!!  cosecha. Reconstruilo con: sort -u $MANIFIESTO > $LEDGER" >&2
155  exit 1
156fi
157echo "==> $PEDIDOS artefactos borrados y VERIFICADOS (0 sobrevivientes) · libres: $ANTES → $AHORA"