CLAUDE.md §3.bis: el scratch de build caía en el overlay desechable, con 223 G al lado sin usar

`work_root` sale de `dirname(store)/work`, y con el store en `/store` el padre es `/`: todo el
scratch iba al overlay de 69 G de la jaula, que además es capa DESECHABLE — la caché de fuentes
vivía en algo que se tira. Mientras tanto `/dev/sdc`, 255 G, estaba al 9 %.

De los 6,8 G de `work/sources`, 5,4 G eran DOS COPIAS del mismo commit de tawasuyu: los árboles se
nombran por receta, no por commit, así que cada receta del monorepo cuesta otros 2,7 G. Queda
anotado que es deliberado (aislamiento del ADR 0012) y que no se deduplica de paso.

Arreglado con enlaces a `/work/sergio/work` en vez de con `TAKANA_WORK`: el override existe y
funciona, pero una docena de scripts llama a `takana build` y un export que hay que recordar se
olvida. Comprobado con un build real sin ninguna variable — rc=0, el árbol cayó en sdc y el hash
salió idéntico al de la corrida anterior. Overlay de 6,9 G a 14 G libres.

Anotado también que el worker NO tiene este problema (un solo disco de 196 G), que los enlaces se
van si la jaula se rehace, y que la premisa del `seal` (rename atómico ⇒ mismo filesystem) ya
estaba rota en el hub antes de esto, porque `/work` y `/store` son discos distintos.
This commit is contained in:
Sergio
2026-09-21 15:00:59 +00:00
parent cc425c5615
commit ffa203910f
+38
View File
@@ -218,6 +218,44 @@ Un directorio **vacío** en el store no es un artefacto: es un nombre. `Store::h
sigue valiendo para cualquier código nuevo — **un ausente falla ruidosamente; un vacío llega hasta sigue valiendo para cualquier código nuevo — **un ausente falla ruidosamente; un vacío llega hasta
el final diciendo que todo fue bien**. el final diciendo que todo fue bien**.
## 3 bis. En el HUB, el scratch de build no cae donde parece — y el disco bueno estaba sin usar
**Medido el 2026-09-21.** `work_root` no es una ruta elegida: sale de `dirname(store)/work`
(`crates/takana-build/src/config.rs`). Con el store en `/store`, el padre es `/` ⇒ **todo el scratch
de build cae en el overlay de la jaula**. En esta caja eso son 69 G compartidos, y el disco de
verdad —`/dev/sdc`, 255 G— estaba **al 9 %, sin usar**.
Dos cosas lo empeoran, y ninguna se ve desde `df`:
- **El overlay es capa DESECHABLE.** `/work` no tiene montaje propio: si la jaula se rehace, los
árboles de fuentes se van con ella. La caché de build vivía en algo que se tira.
- **Los árboles se nombran por RECETA, no por commit.** `boveda` y `shuma-pregunta` salen del mismo
`b80f7567…` de tawasuyu y ocupaban **2,7 G cada una** — 5,4 G de los 6,8 G totales eran el mismo
contenido dos veces. Cada receta nueva de ese monorepo cuesta otros 2,7 G. Es deliberado (árbol
por receta = el aislamiento que evita el destrozo del ADR 0012); **no deduplicar de paso.**
**Arreglado con enlaces, no con una variable de entorno**, porque una docena de scripts llama a
`takana build` y un `export` que hay que recordar se olvida:
```sh
ln -sfn /work/sergio/work/sources /work/sources
ln -sfn /work/sergio/work/out /work/out
```
Comprobado con un build real contra un store tirable y **sin ninguna variable**: `rc=0`, el árbol
cayó en `sdc` y el hash salió idéntico al de la corrida anterior. El overlay pasó de **6,9 G a 14 G
libres**. Existe `TAKANA_WORK` como override (junto a `TAKANA_LAB`/`ROOTFS`/`ZIG`/`CACHE`) y
funciona, pero el enlace no se puede olvidar.
**Si la jaula se rehace, los enlaces se van y el scratch vuelve al overlay en silencio** — nada
falla, sólo se llena otra vez. Rehacerlos es lo de arriba; el contenido sigue en `/work/sergio/work`.
**El WORKER no tiene este problema:** un único disco de 196 G con todo encima (`/`, `/opt/takana`,
su store), así que ahí `work_root` y el store comparten filesystem y el `seal` —que es un `rename`,
atómico sólo dentro del mismo fs— cumple su premisa. **En el hub esa premisa ya estaba rota** antes
de este cambio: `/work` en `sda4` y `/store` en `sdb` son discos distintos. Mover el store al disco
grande lo restauraría, pero es su propia unidad de trabajo — toca la granja, el hub y los scripts.
## 4. La superficie de la CLI va en INGLÉS; los mensajes, en castellano ## 4. La superficie de la CLI va en INGLÉS; los mensajes, en castellano
Subcomandos, flags y nombres de opciones: **inglés** (`build`, `hash`, `hydrate`, `mirror push`, Subcomandos, flags y nombres de opciones: **inglés** (`build`, `hash`, `hydrate`, `mirror push`,