Integración software ↔ robot¶
Cómo el catálogo dispara la conexión física. La pieza clave es el hook special remote de git-annex: cuando se pide un archivo ausente,
ANNEX_ACTION=retrieveejecuta un script que ordena al robot conectar el disco. El modelo conceptual es un HSM con stub files, y la latencia del recall es inherente.
Contexto¶
Resuelve el gap "latencia del VFS" y la comparación de herramientas de catálogo. Conecta sistema archivos virtual indexado con mecanica pick and place y power y hot plug.
Contenido¶
El punto de integración: hook de git-annex¶
git-annex soporta hook special remotes: cada operación corre un comando shell con variables de entorno (ANNEX_ACTION ∈ {store, retrieve, remove, checkpresent}, ANNEX_KEY). El flujo del proyecto:
- El usuario pide un archivo que vive en un disco offline.
- git-annex invoca el hook con
ANNEX_ACTION=retrieve+ANNEX_KEY. - El script traduce key → serial del disco (identificacion discos) → slot físico.
- Ordena al robot (control movimiento grbl) mover + conectar + energizar (power y hot plug).
- Monta el disco, copia el contenido, devuelve éxito a git-annex.
→ No hace falta escribir un VFS desde cero: git-annex ya orquesta "qué key, qué disco, recuperá"; solo se reemplaza su mensaje manual "enchufá el disco X" por la acción del robot.
El modelo: HSM con stub files¶
El comportamiento deseado es el de un HSM (Hierarchical Storage Management): los archivos migrados quedan como stub files (symlinks/placeholders) que parecen locales; al accederlos, el sistema hace recall transparente desde el tier lento — "transparent to the user, though access time is slower". git-annex implementa justo esto (pointer files + get). Un VFS FUSE encima sería más transparente (un open() bloqueante dispara el recall) pero es opcional.
La latencia es inherente y define el caso de uso¶
El "wake" completo = mover (s) + spin-up (5–10 s, power y hot plug) + mount. Realista: decenas de segundos por disco frío. Implicaciones:
- ❌ No sirve para acceso interactivo tipo "abrir un video y hacer seek".
- ✅ Sirve para recuperación batch / archivística: "traeme estos N archivos / esta carpeta", restore de backup, indexado.
- Mitigación: cachear metadata, thumbnails y previews en disco caliente para navegar el catálogo sin energizar nada; agrupar pedidos por disco para amortizar el wake.
Elección de herramienta según arquitectura¶
| Vía | Herramienta | Por qué |
|---|---|---|
| Robot / discos offline | git-annex | Diseñado para archive drives offline; sabe qué disco tiene cada archivo y tiene hooks para automatizar el recall. |
| MAID / todo conectado | mergerfs + SnapRAID | Poolea discos en un mount único con paridad; solo gira el disco accedido (spin-down). Requiere los discos conectados. |
Ambas comparten la idea de "no tener todo girando"; difieren en si el disco está enchufado (MAID) o guardado (robot). Ver swap robotico vs spin down y economia energia conectividad.
Relaciones¶
- Implementa el cerebro de: sistema archivos virtual indexado.
- Usa: git annex, identificacion discos.
- Dispara: mecanica pick and place, power y hot plug.
- Decide entre arquitecturas: swap robotico vs spin down.
Citas / evidencia¶
- "ANNEX_ACTION environment variable, including 'store'... 'retrieve'... allows you to trigger custom external scripts when content is requested" — software catalogo y identificacion
- HSM recall "transparent to the user, though access time is slower"; stub file "appears as though the file is still resident on the local disk" — software catalogo y identificacion
Abierto / gaps¶
- Probar el hook real de git-annex end-to-end con un script dummy del robot.
- ¿Existe un FUSE listo que haga recall on-demand sobre git-annex, o hay que escribirlo?