El 2026-08-28 `/dev/sda2` llegó al 100% —CERO bytes— porque
`/home/sergio/go/pkg/mod` pasó de 498 MB a 25 G construyendo las recetas Go.
El vigía miraba store/work-sources/CARGO_HOME y no eso, así que no avisó.
Los builds Go morían con `write /home/sergio/go/pkg/mod/cache/download/…: no
space left on device`, que no se lee como un fallo de disco del build porque la
ruta no está en el repo (httpx, hugo, impl…). Y un `/` lleno no rompe una
tanda: rompe la máquina (gitea, caddy).
GOPATH se movió a /mnt/cosecha/gopath por symlink, igual que ~/.cargo. Se añade
al vigía igualmente, para que lo vea si alguien lo devuelve a `/`.
El store de hammer se mudó al volumen harkaq-cosecha (/dev/sdb, bind-mount
sobre ./store, work/sources y work/repos; CARGO_HOME también). Desde eso,
medir `$ROOT` mide /mnt/vvv, que hammer COMPARTE con tawasuyu y que ya no
es donde gasta.
Por qué se movió: tawasuyu repuebla su target a ~62 G/h. El 27/08 se le
liberaron 92,9 GiB con cargo clean, se lanzó la campaña con 64 G libres y
70 min después el disco estaba en 237 MB — la tanda abortó en cosmic-applets
por un disco que no era suyo. El cargo clean sirve para un pico, no para
financiar una campaña larga: el vecino lo recupera entero en una hora.
El vigía ahora toma el mínimo de {STORE, work/sources, CARGO_HOME}. Con
$ROOT veía 46 G y bajando; ahora ve 84 G reales.
El fichero de orden estaba fijo en la linea 69 y lo regeneraba el bloque python
en cada corrida, asi que no habia forma de pasarle una lista concreta. Con el
grafo ya corregido quedan 17 recetas que cierran las SEIS imagenes (base, cli,
sway, mirada, cosmic, gnome) y ninguna esta bloqueada; correr el corpus entero
para llegar a ellas es absurdo.
Ahora `ORDEN_IMPUESTO=1 ORDEN=<fichero>` usa la lista del que llama y hereda
gratis lo que hace util a este script: el flock de la regla 1, el vigia de disco
de dos sistemas de ficheros y el log por receta.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Xd5DComN9Nu47TBpYMBHBn
Media `df` sobre el repo y nada mas. Pero las recetas Rust no gastan solo ahi:
`cargo vendor` copia DESDE `~/.cargo/registry`, que en gioser esta en `/` (74 G)
y no en `/mnt/vvv` (255 G). Hoy eso eran 138 G libres segun el vigia y 19 G de
verdad — luz verde mientras el que se llenaba era el otro, y llenar `/` no
rompe una tanda, rompe la maquina.
Ahora toma el MINIMO de los dos FS (el del repo y el de CARGO_HOME). Si
comparten FS, `df` devuelve lo mismo dos veces y es inocuo.
La purga tambien se queda corta y crece:
- `work/repos/*`, los clones --mirror de gitea de las hub-only. Se re-clonan.
- `$CARGO_HOME/registry` como ULTIMO recurso y CON GUARDA: el act-runner de
tawasuyu corre como el mismo usuario y comparte ese ~/.cargo. Purgarlo con un
`cargo` ajeno en vuelo le arranca los ficheros a SU compilador. Se pregunta
por el codigo de salida de `pgrep`, no por su stdout.
De paso queda dicho en la cabecera que CARGO_HOME se vigila: en gioser el
driver se lanza con el suyo propio dentro del volumen, y asi hammer deja de
gastar `/`.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Xd5DComN9Nu47TBpYMBHBn
La tanda del 2026-08-13 ABORTO con 7 G libres despues de haber purgado a los
25: una sola receta se comio >18 G entre purga y purga. Son los cargo vendor
de las recetas Rust grandes, que sueltan varios GB cada una.
Con 40/15 la purga ocurre ANTES de que una receta gorda agote lo que queda,
en vez de justo despues. El guardian de aborto hizo su trabajo —paro sin
llenar el disco y sin corromper nada— pero llegar a el significa perder la
tanda; el objetivo es no llegar.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Con un worker el corpus son ~7 dias (medido: ~9 min/receta sobre 1161).
Repartirlo es la unica forma de bajarlo, y no hace falta planificador
central: cada worker construye SU parte y las deps que le falten se las
construye `hammer build` solo. Al cosechar todo converge en el mismo store
porque las direcciones coinciden — eso lo PRUEBA el paso 4 de
farm-lab-sync.sh, no se supone.
El reparto es por INDICE (i-1, i-1+N, ...) y no por bloques contiguos: el
orden ya esta por objetivo, asi que bloques contiguos le darian a un worker
todo el tramo GUI —el mas lento— y a otro solo hojas rapidas. Intercalando,
todos avanzan por el mismo terreno a la vez.
⚠ Hay trabajo DUPLICADO y es deliberado: dos workers con recetas que cuelgan
de qtbase lo construyen los dos. Sale a cuenta frente a serializar, pero con
4 workers no son 4x, son ~3x.
Un log por shard, o se pisan. Verificado: los 4 shards suman 1161 exactas y
rechaza 5/4 y `abc`.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sus deps.build resuelven contra el directorio hermano, que en .deferred no
existe: fallan al instante con «no pude cargar la dep de build 'zlib' de
'git' (recipes/incoming/.deferred/zlib.toml)». Son 25.
Intentarlas no es solo inutil: mete 25 FALLA en el log que parecen roturas
del corpus y esconden las de verdad. Un log lleno de fallos esperados es un
log que nadie lee.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Hace falta cada vez que cambie la imagen del lab, porque desde 58d3161 el
toolchain entra en hash_inputs y eso mueve el hash de TODO el corpus. Es el
precio explicito de cambiar de compilador; antes se pagaba sin enterarse.
EN SERIE bajo el flock compartido (ADR 0012): dos builds que compartan una
dep se pisan el arbol de fuentes y queda roto para siempre.
REANUDABLE sin estado propio: pregunta `hammer hash --check` (~2 ms) en vez
de llevar un fichero de progreso. Matarlo y relanzarlo continua donde iba.
POR OBJETIVO, no alfabetico: hay 1186 recetas y solo 168 alcanzan una imagen.
Ordenado por targets.toml primero, cada perfil que cierra es utilizable ya;
por orden alfabetico, tras un dia de maquina no habria ni una imagen.
Dos correcciones en el camino: usar los nodos de build-state marcaba 1161 de
1161 como prioritarias (ese grafo ES el corpus entero, no las clausuras), y
`glob('recipes/**/*.toml')` se dejaba 25 ficheros fuera — os.walk da 1186,
que es lo que cuenta `find`.
La purga de work/sources va ENTRE recetas, con nada corriendo. Purgar con un
build en vuelo le arranca los ficheros al compilador: paso el 2026-08-10 y se
llevo un kernel a medias.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sergio