churn del store: eran CUATRO rutas de cosecha, no una — arreglé una y di el bucle por cerrado

Podé el store por tercera vez hoy: 363 artefactos superados, 24 G. Comparado con la poda de la
tarde: **362 en común**. Volvieron otra vez, pese al arreglo de esta tarde.

LA CAUSA de que el arreglo no sirviera: puse el `--exclude-from` del registro de podados sólo en
`farm-sync.sh`, y el latido NO usa ese script. `cosecha-cron.sh` tiene su PROPIO rsync del store
(línea 71), y corre cada 30 minutos por cron ⇒ una poda de 24 G quedaba deshecha en menos de una
hora. Los tres commits de «cosecha granja» de la madrugada son exactamente eso.

Y al ir a arreglarlo, en vez de parchear y seguir, busqué si había más: **son CUATRO** las rutas
que bajan el store del worker — `cosecha-cron.sh`, `farm-sync.sh`, `harvest-go.sh` y
`farm-down.sh`. Tenía protegida una de cuatro.

El error de método vale más que el bug: arreglar una de varias copias y declarar victoria es
PEOR que no arreglar, porque el síntoma se atenúa lo justo para dejar de mirar. Lo que lo
delató fue comparar los manifiestos de dos podas (`comm -12`), no leer código. Dos podas con el
mismo número no son coincidencia — ya está anotado como regla, y hoy la regla pagó dos veces.

Las cuatro llevan ahora el mismo `--exclude-from` y una nota que dice que son cuatro, para que
la quinta —si aparece— nazca protegida.

Disco: 112 G → 136 G tras la poda de ahora.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-08-07 21:52:46 -04:00
co-authored by Claude Opus 5
parent dd8baa7560
commit 39b88ebd2a
3 changed files with 29 additions and 3 deletions
+13 -1
View File
@@ -68,7 +68,19 @@ else
continue continue
fi fi
# 2. RECOGE: store sellado worker→laptop (CAS, merge seguro). # 2. RECOGE: store sellado worker→laptop (CAS, merge seguro).
if rsync -az --exclude /.dmerge -e "$SSH" "root@$ip:$REMOTE/store/" "$ROOT/store/" 2>&1 | tail -2; then # ── ⚠ EXCLUIR LO YA PODADO, O LA POda SE DESHACE SOLA ─────────────────────────────────────
# El worker NO se poda nunca, así que conserva los artefactos superados y este rsync los
# devolvía enteros. Con el latido cada 30 min, una poda de 24 G quedaba deshecha en menos de
# una hora: medido el 2026-08-07, tres podas seguidas borraron LOS MISMOS 362 artefactos.
#
# El mismo arreglo está en `farm-sync.sh` — y ahí estuvo el error de método: lo puse allí, di el
# bucle por cerrado, y la churn siguió porque **hay DOS rutas que bajan el store** y el latido
# usa ésta. Arreglar una de dos copias y declarar victoria es peor que no arreglar: el síntoma
# se atenúa lo justo para dejar de mirar. Si aparece una tercera copia, va con el mismo exclude.
LEDGER="$ROOT/work/store-gc-superados.txt"
EXCL=""
[ -s "$LEDGER" ] && EXCL="--exclude-from=$LEDGER"
if rsync -az --exclude /.dmerge $EXCL -e "$SSH" "root@$ip:$REMOTE/store/" "$ROOT/store/" 2>&1 | tail -2; then
echo " cosecha ✓" echo " cosecha ✓"
else else
echo " ⚠ cosecha falló — sigo" echo " ⚠ cosecha falló — sigo"
+8 -1
View File
@@ -47,7 +47,14 @@ while read -r name ip; do
fi fi
echo "==> cosechando store de $name ($ip)" echo "==> cosechando store de $name ($ip)"
if rsync -az -e "$SSH" "root@$ip:$REMOTE/store/" "$ROOT/store/"; then # ⚠ `--exclude-from` del registro de podados: el worker NO se poda, así que devolvería los
# artefactos superados y desharía la poda (24 G por vuelta). Misma protección que en
# `cosecha-cron.sh`, `farm-sync.sh` y `store-gc.sh` — son CUATRO rutas que bajan el store del
# worker y la protección tiene que estar en las cuatro. Se descubrió tras arreglar sólo una y
# comprobar que la churn seguía.
LEDGER_GC="$ROOT/work/store-gc-superados.txt"
EXCL_GC=""; [ -s "$LEDGER_GC" ] && EXCL_GC="--exclude-from=$LEDGER_GC"
if rsync -az $EXCL_GC -e "$SSH" "root@$ip:$REMOTE/store/" "$ROOT/store/"; then
echo "==> destruyendo $name" echo "==> destruyendo $name"
if hcloud server delete "$name" >/dev/null 2>&1; then if hcloud server delete "$name" >/dev/null 2>&1; then
harvested=$((harvested + 1)) harvested=$((harvested + 1))
+8 -1
View File
@@ -68,7 +68,14 @@ git pull --rebase --autostash origin main 2>&1 | tail -2 || echo "$(STAMP) WARN:
# 2. bajar el store sellado del worker. # 2. bajar el store sellado del worker.
echo "$(STAMP) bajando store del worker…" echo "$(STAMP) bajando store del worker…"
rsync -az -e "$SSH" "$VPS:$REMOTE/store/" "$STORE/" 2>&1 | tail -1 || { echo "$(STAMP) ERROR: rsync store falló"; exit 1; } # ⚠ `--exclude-from` del registro de podados: el worker NO se poda, así que devolvería los
# artefactos superados y desharía la poda (24 G por vuelta). Misma protección que en
# `cosecha-cron.sh`, `farm-sync.sh` y `store-gc.sh` — son CUATRO rutas que bajan el store del
# worker y la protección tiene que estar en las cuatro. Se descubrió tras arreglar sólo una y
# comprobar que la churn seguía.
LEDGER_GC="$(cd "$(dirname "$0")/../.." && pwd)/work/store-gc-superados.txt"
EXCL_GC=""; [ -s "$LEDGER_GC" ] && EXCL_GC="--exclude-from=$LEDGER_GC"
rsync -az $EXCL_GC -e "$SSH" "$VPS:$REMOTE/store/" "$STORE/" 2>&1 | tail -1 || { echo "$(STAMP) ERROR: rsync store falló"; exit 1; }
mkdir -p "$REVIEW" mkdir -p "$REVIEW"
promoted=""; rejected=""; skipped="" promoted=""; rejected=""; skipped=""