FADU FS-SSD: cómo lleva las operaciones de archivos al SSD

FADU FS-SSD lleva la gestión de archivos dentro de la unidad y transmite operaciones NFSv3 mediante comandos NVMe estándar. La arquitectura está pensada para que GPU, DPU y tarjetas de red compatibles soliciten archivos directamente; un cliente kernel, en cambio, sigue usando software del host.

Qué cambia dentro del SSD

FS-SSD incorpora funciones como buscar rutas, gestionar permisos y asignar archivos a la memoria flash. Su capa de archivos deriva de F2FS y está diseñada junto con la capa de traducción flash (FTL), que relaciona las direcciones lógicas con las físicas de la memoria NAND. FADU describe operaciones NFSv3 dentro de comandos NVMe estándar, con conexión por PCIe o NVMe-oF sobre RDMA o TCP.

La propuesta evita que cada solicitud de archivo tenga que recorrer la pila tradicional del host, con sus capas de sistema de archivos y de bloques, en las rutas directas previstas. FADU calcula que la memoria DRAM dedicada a metadatos equivale aproximadamente al 0,1 % de la capacidad NAND, cerca de 1 GB por TB; alrededor del 95 % de esa DRAM podría funcionar como caché de nodos de acceso frecuente.

Acceso directo y cliente kernel

El acceso directo de una GPU, DPU o NIC puede evitar la ruta del sistema de archivos del host. El cliente kernel no: presenta un punto de montaje, pero continúa dependiendo del kernel y de la CPU del host.

FADU presentó esa distinción como una forma de descargar ciertas operaciones de archivos en el almacenamiento. No significa que todos los modos de uso prescindan del trabajo del host. En las cifras aleatorias de 4 KB comunicadas por FADU, el cliente kernel de FS-SSD quedó por debajo de Ext4, mientras que el cliente SPDK obtuvo valores superiores en esa carga.

Qué miden las cifras preliminares

En su libro blanco del 12 de octubre de 2026, FADU comunicó cerca de 460.000 operaciones por segundo en una prueba remota de Filebench, desde 16 núcleos del servidor hasta uno. El ensayo usó un controlador FC6161 Gen6 en un host PCIe 5.0. Para comparar, FADU informó unos 150.000 ops/s con Linux NFS sobre RDMA a 16 núcleos y unos 40.000 ops/s con uno. Son resultados preliminares de la empresa.

La carga de Filebench recreaba un servidor con muchos accesos a metadatos: incluía 10.000 archivos en una estructura de directorios, archivos de 128 KB de tamaño medio y 50 hilos de cliente. El resultado de 460.000 ops/s se mantuvo aproximadamente al reducir los núcleos del servidor de 16 a uno.

FADU también publicó resultados preliminares de E/S aleatoria de 4 KB. Los valores siguientes están expresados en MB/s:

A partir de esas cifras de FADU, el cliente SPDK de FS-SSD alcanza aproximadamente 1,43 veces el resultado de Ext4 en lectura aleatoria y 1,54 veces en escritura aleatoria de 4 KB. El cliente kernel registra 8.070 MB/s en lectura y 4.320 MB/s en escritura, frente a 9.120 y 4.560 MB/s de Ext4, respectivamente. Son comparaciones de resultados comunicados por FADU, no mediciones independientes.

Tom’s Hardware advirtió que los 13.240 MB/s de escritura aleatoria de SPDK sobre bloques sin procesar superaban el ancho de banda de programación NAND de unos 12 GB/s citado por FADU y podían no corresponder a un estado estable. En otra prueba, FADU comunicó una reducción del 63 % en la amplificación de escritura frente a F2FS del host, con una carga mixta secuencial y aleatoria. Tom’s Hardware identificó ese ensayo como una prueba en NVMeVirt, un emulador de SSD por software, no en una unidad física.

Escrituras concurrentes y seguridad

La implementación descrita no tiene bloqueo entre hosts. Si dos clientes escriben en la misma ubicación, las escrituras se aplican completas y en orden, y prevalece la última. Los clientes GPU y SPDK deben coordinar las escrituras desde sus aplicaciones; un servidor de metadatos pNFS puede proporcionar coordinación a escala.

FADU describe autenticación basada en capacidades y señala que prevé incorporar Kerberos. El informe de Tom’s Hardware indicó que la versión descrita carecía de listas de control de acceso (ACL) y de otras funciones de sistemas de archivos. Para el cifrado, el controlador FC6161 ofrece compatibilidad con TCG Opal, el estándar de unidades con autocifrado.

Objetivos para 2027 y estimaciones de JBoF

FADU fijó como objetivos obtener resultados con un host Gen6 para el primer trimestre de 2027, entregar muestras a socios en el tercer trimestre y preparar un diseño de referencia JBoF sin host antes de terminar 2027. JBoF es una arquitectura de almacenamiento basada en unidades conectadas a una red, sin un servidor convencional dedicado a cada conjunto de discos. El diseño previsto usaría DPU Xsight Labs E1.

Para ese JBoF, el modelo de FADU estima un 42 % menos de consumo, un 57 % menos de coste por servidor de 16 unidades, 1,7 veces la densidad de rack y un 60 % menos de coste total de propiedad a cinco años. Son proyecciones del modelo de la empresa, no resultados operativos medidos.