En Linux llevamos años asumiendo que, para leer un fichero, hay un camino casi inevitable: bloque → I/O → page cache → copia a memoria de usuario. Es un flujo robusto, afinado durante décadas… pero también costoso cuando lo que se busca es latencia mínima, máxima eficiencia y reutilización real de páginas entre entornos.
Ahí es donde entra DAXFS, un experimento de filesystem que se apoya en DAX (Direct Access) para operar directamente sobre una región de memoria física contigua, evitando el “stack” tradicional: sin page cache, sin buffer heads y sin copias innecesarias. La idea es agresiva: que los reads se resuelvan como cargas directas desde la región mapeada, y que un mismo “imagen base” pueda compartirse entre múltiples kernels, contenedores o incluso dispositivos.
La pieza clave: DAX, pero llevada al límite
DAX es la infraestructura del kernel pensada para acceder de forma directa a memorias tipo PMEM u otras regiones expuestas como DAX, precisamente para saltarse la page cache y reducir sobrecostes cuando el almacenamiento se comporta más como memoria que como disco.
DAXFS intenta construir encima de eso un modelo de filesystem “imagen + ramas” que se coloca en una región de memoria compartida y se monta como si fuera un sistema de archivos tradicional… pero con un camino de datos mucho más corto.
Cómo funciona DAXFS: base read-only + ramas copy-on-write
Según su diseño público, DAXFS combina:
- Una imagen base de solo lectura (ideal para rootfs o datasets que no deberían duplicarse).
- Ramas (branches) copy-on-write, donde cada rama mantiene un delta log con las modificaciones.
- Índice en memoria (tipo rb-tree) para acelerar lecturas consultando primero los deltas y luego “cayendo” a la base compartida.
El matiz interesante está en su semántica de ramas: no busca ser “Git para sistemas de archivos”. DAXFS plantea ramas mutuamente excluyentes: al “commit” de una rama se descartan ramas hermanas; al “abort”, se vuelve atrás. Está pensado para modificaciones especulativas con “un único camino ganador”, un patrón que encaja con flujos de automatización y agentes que prueban cambios y se quedan con la mejor opción.
Por qué aparece ahora: contenedores, multikernel y aceleradores
DAXFS nace con un foco concreto: entornos multikernel donde varias instancias de kernel comparten una región de memoria física. Su caso de uso original: arrancar imágenes tipo Docker/rootfs desde memoria compartida, evitando I/O de red o duplicaciones de datos entre instancias.
Pero el propio proyecto señala escenarios que reflejan hacia dónde se mueve la infraestructura moderna:
- Compartir rootfs entre contenedores: una misma base, ramas para las capas modificables, sin duplicar page cache ni recurrir a la lógica de copy-up típica.
- Memoria persistente y CXL: colocar una imagen DAXFS en regiones expuestas como DAX (por ejemplo, memory pooling), para compartir “un filesystem” sin tráfico de red.
- Datos para GPU/FPGA/SmartNIC: montar imágenes alojadas en memoria accesible por dispositivos, con el objetivo de acercarse a un zero-copy práctico en datasets como tablas, índices o pesos de modelos.
Aquí entra una palabra clave: dma-buf. En Linux, dma-buf es el mecanismo estándar para compartir buffers entre subsistemas y drivers, permitiendo que distintos dispositivos y componentes del kernel trabajen sobre la misma memoria sin duplicarla.
DAXFS contempla montar la imagen usando un file descriptor de dma-buf a través del new mount API (fsopen/fsconfig/fsmount), precisamente porque un FD no cabe como simple string en opciones de mount.
¿En qué se diferencia de tmpfs, overlayfs o EROFS?
La comparación con tecnologías “familiares” es inevitable, y el proyecto la hace explícita:
- tmpfs/ramfs: rápidos, sí, pero read-write y “por instancia”. Si N contenedores usan el mismo rootfs en tmpfs, la memoria real se multiplica; además, hay que poblarla copiando datos “hacia dentro”.
- overlayfs: resuelve capas, pero con límites (profundidad, complejidad) y el coste de copy-up y page cache en la capa superior.
- EROFS: muy eficiente en read-only, pero su diseño está tan ligado a la inmutabilidad que añadir branching lo rompería o lo encarecería drásticamente.
DAXFS, en cambio, apuesta por una combinación menos común: read-only compartido + “mutabilidad” por deltas, sin convertir eso en un sistema generalista para cualquier carga.
Un vistazo práctico: comandos de montaje y ramas
El propio repositorio muestra un flujo de uso que, en laboratorio, ayuda a entenderlo:
# Montar indicando una región física y una rama writable
mount -t daxfs -o phys=0x100000000,size=0x10000000,branch=main,rw none /mnt
# Crear rama (cambia implícitamente a ella)
daxfs-branch create feature -m /mnt -p main
# Listar ramasdaxfs-branch list -m /mnt
# Confirmar o descartar cambios
daxfs-branch commit -m /mnt
daxfs-branch abort -m /mnt
Ese “commit/abort” con descarte de ramas hermanas define bastante bien el enfoque: no pretende ser un filesystem de propósito general, sino un mecanismo para compartir imágenes y permitir modificaciones controladas, con trazabilidad en deltas.
Lo importante para sysadmins: dónde encaja y dónde no
DAXFS suena prometedor, pero conviene leerlo como lo que es: un experimento.
Encaja especialmente bien si:
- Necesitas muchas instancias (kernels/contendores) compartiendo el mismo rootfs o dataset sin duplicación.
- Tienes un entorno con memoria compartida real (multikernel, PMEM, CXL, heaps exportables).
- Buscas explorar pipelines con aceleradores donde el coste de mover datos y duplicarlos manda más que el compute.
No encaja (todavía) como sustituto de ext4/xfs/btrfs para servidores generalistas:
- Requiere regiones contiguas y una operativa distinta (reservas, mapeos, lifecycle).
- El modelo de escritura es por deltas y ramas, no un write path tradicional para cargas “normales”.
- Cualquier adopción real pasa por madurez, auditoría, pruebas de recuperación y, sobre todo, ver si el ecosistema Linux lo considera útil a largo plazo.
vía: Github
