FADU, diseñadora de controladores para SSD, anunció en el OCP Global Summit 2026 su nuevo File-Semantic SSD (FS-SSD), un dispositivo que lleva el sistema de archivos al interior del propio disco, informó Tom's Hardware. Según detalla FADU en un documento técnico, eso permite que GPU, DPU y tarjetas de red abran y lean archivos "sin sistema de archivos en el host, sin capa de bloques y sin CPU de servidor de almacenamiento en el camino". FADU le dijo a Tom's Hardware Premium que espera tener muestras para socios en el tercer trimestre de 2027.
FADU es una diseñadora de controladores para SSD sin fábrica propia, con sede en Seúl, Corea del Sur. Su tecnología FS-SSD apunta a mejorar la ruta de control, porque la ruta de datos ya se trasladó a los aceleradores hace años. Las mediciones de FADU muestran que el sistema de archivos, junto con las capas de bloques, puede consumir cerca de 30% de los ciclos de CPU en una carga de lectura aleatoria con GPUDirect Storage (GDS). La compañía señala que las opciones que se saltan esas capas renuncian a los archivos, y asegura que su solución ofrece lo mejor de los dos mundos.
¿Cómo rinde frente a NFS sobre RDMA?
En una prueba preliminar propia de Network File System (NFS) sobre NVMe, con un disco basado en su controlador FC6161 Gen6 montado en un host PCIe 5.0, el rendimiento remoto de archivos se mantuvo estable mientras el servidor bajaba de lo que FADU llama 16 núcleos a uno solo, con cerca de 460.000 operaciones por segundo.
Las operaciones NFSv3 viajan dentro de comandos NVMe estándar, y el disco se encarga de buscar las rutas, controlar el acceso y mapear los archivos a la memoria flash. Comparado con NFS sobre RDMA en Linux, la diferencia es grande. Esa alternativa logró un tercio de las operaciones por segundo con 16 núcleos, cerca de 150.000, y apenas 40.000 con un núcleo. La tecnología sigue "en desarrollo activo", y FADU le dijo a Tom's Hardware Premium que espera resultados en un host Gen6 para el primer trimestre de 2027.
FADU eligió NFSv3 porque es "pequeño (21 operaciones), independiente del sistema operativo y del sistema de archivos, y sin estado", con poca carga para el firmware. FS-SSD funciona hoy sobre PCIe, y NVMe-oF sobre RDMA y TCP funciona sin necesidad de un transporte nuevo. Tom's Hardware considera acertado reutilizar un protocolo existente.
¿Qué hay adentro del disco?
Por dentro, el sistema de archivos y la capa de traducción de la flash se fusionan con una capa de archivos derivada de F2FS. Los bloques de nodos y de datos se alinean con las páginas naturales de la flash, y las secciones con las unidades de borrado correspondientes, así que la tabla de nodos de F2FS se convierte en un "mapa de archivos" que apunta los ID de nodo a direcciones físicas de la flash.
Una ventaja grande es que la carga de metadatos de mapeo en DRAM es bastante menor. Usa la misma cantidad de DRAM que un SSD estándar, cerca de 0,1% de la capacidad NAND (alrededor de 1 GB por TB), que un SSD común llena casi por completo con su tabla de mapeo. En el FS-SSD, cerca del 95% de esa DRAM puede funcionar como caché de nodos para la ruta más usada.
Un solo recolector de basura reemplaza a dos, lo que evita lo que FADU llama la "doble GC" de F2FS en el host, donde la limpieza del sistema de archivos y la recolección de basura del propio disco se amplifican entre sí. Según la compañía, la amplificación de escritura también es 63% menor que con F2FS en el host, en una carga mixta secuencial y aleatoria con el prototipo de investigación de FADU. La empresa le aclaró a Tom's Hardware Premium que ese prototipo corre cargas sintéticas de fio sobre NVMeVirt, un emulador de SSD por software de código abierto de la Universidad Nacional de Seúl, así que no es un resultado en hardware.
Acceso sin pasar por el host
Lo más importante de este método es que asegura el acceso sin host. La GPU arma comandos NFS sobre NVMe en colas dentro de su propia memoria, que puede ser HBM. Otra opción es que una SmartNIC o DPU remota, con descarga de destino NVMe-oF, deje los comandos en la cola de envío del disco. Los datos van del SSD a la tarjeta de red por DMA punto a punto sobre PCIe y salen como escrituras RDMA. Los casos de uso que FADU nombra de forma explícita incluyen lecturas de archivos y checkpoints desde la GPU, entrega de contenido HTTP servida por una DPU y un servidor de archivos JBoF (just a bunch of flash).
Las pruebas y sus números
Las cifras de la prueba interna de FADU vienen de un cliente y un servidor con Intel Core i5-13600K, una CPU de 20 hilos que llega a 5,1 GHz, con 128 GB de DDR5 y una tarjeta de red Mellanox ConnectX-6 de 100 Gbps. Las pruebas sintéticas se comparan con fio entre F2FS y Ext4 sobre firmware de bloques y el FS-SSD mediante un cliente de kernel y un cliente de espacio de usuario SPDK. La prueba secuencial usa 1 hilo, profundidad de cola (QD) 128 y bloques de 128 KB, y la aleatoria usa 4 hilos, la misma QD128 y bloques de 4 KB.
Según Tom's Hardware, esos tamaños de bloque son típicos de cargas de cliente, así que son una medida justa. Los resultados preliminares detallados están en la tabla.
| Configuración | Lectura secuencial (MB/s) | Escritura secuencial (MB/s) | Lectura aleatoria 4 KB (MB/s) | Escritura aleatoria 4 KB (MB/s) |
|---|---|---|---|---|
| F2FS | 14.120 | 4.510 | 7.850 | 3.980 |
| Ext4 | 14.130 | 7.050 | 9.120 | 4.560 |
| FS-SSD (cliente de kernel) | 14.140 | 11.940 | 8.070 | 4.320 |
| FS-SSD (cliente SPDK) | No informado | No informado | 13.000 | 7.030 |
| Bloque crudo (SPDK) | No informado | No informado | 13.990 | 13.240 |
Frente a SPDK sobre el disco crudo, con cifras que FADU entregó a Tom's Hardware, el cliente SPDK del FS-SSD conserva cerca del 93% en lectura aleatoria de 4K y el 53% en escritura aleatoria de 4K medidos con fio, o sea un costo de alrededor de 7% y 47% por la capa de archivos dentro del disco. Aunque los 13.240 MB/s de escritura aleatoria del disco crudo superan los cerca de 12 GB/s que FADU indica como ancho de banda de programación de la NAND, esas corridas probablemente no estaban en régimen estable.
El resultado de Filebench es el más interesante, porque las ganancias aleatorias de SPDK aplican también a un dispositivo de bloques común. Debería ser la carga más favorable para esta tecnología, ya que el servidor de archivos de Filebench es pesado en metadatos y tiene una carga de host relativamente alta. FADU dice que usa 10.000 archivos en un árbol de varios niveles, con un ancho medio de directorio de 20, un tamaño medio de archivo de 128 KB y 50 hilos de cliente.
Hay que recordar que, aunque la prueba se hizo con un disco Gen6, los resultados son en un host PCIe 5.0. Por eso toda configuración de lectura secuencial topa en cerca de 14,1 GB/s, que es más o menos el límite del enlace. El banco de pruebas además usa una CPU de escritorio de consumo, y el servidor NFS de un solo núcleo es un ejemplo de vitrina. Según los cálculos de Tom's Hardware, el cliente de kernel queda 11,5% por detrás de Ext4 en lectura aleatoria y 5,3% en escritura aleatoria.
Bloqueos, permisos y seguridad
Una pregunta difícil, en general, es cómo se coordinan los escritores concurrentes de GPU, DPU y host, y cómo se mantiene coherente la caché de páginas de un montaje de kernel con el acceso desde la GPU. Según la especificación pNFS Flexible File Layout (RFC 8435), los dispositivos de almacenamiento NFSv3 "siempre se tratan como débilmente acoplados", lo que significa que "no se puede soportar el bloqueo obligatorio por rango de bytes".
Las credenciales que viajan dentro del comando NVMe también pueden tener problemas de seguridad, porque los dispositivos débilmente acoplados solo obtienen "un nivel de seguridad equivalente a AUTH_SYS", el esquema básico de NFS en el que el servidor confía en los ID de usuario y grupo que envía el cliente. El material publicado por FADU tampoco describe funciones como instantáneas, manejo de cifrado, cuotas, ACL o manejo de caídas. La ausencia de estado es lo que hace funcionar el sistema, pero no resuelve todos los problemas, y la confianza se traslada a otra parte.
Ante las preguntas de Tom's Hardware, FADU respondió que no hay bloqueo entre hosts, porque no implementó el gestor de bloqueos de NFS. El disco aplica cada escritura completa y en orden. Si dos escrituras caen en el mismo lugar, gana la segunda, el esquema conocido como last-writer-wins. La coordinación depende de los clientes. Los montados en el kernel obtienen los bloqueos consultivos habituales entre ellos, los clientes de GPU y SPDK se coordinan en la aplicación, y a escala un servidor de metadatos pNFS se encarga de coordinar. La caché también funciona como en NFS común con los clientes de kernel, o no existe en los clientes de GPU y SPDK. Es el comportamiento normal de NFSv3.
El disco tiene que contrastar él mismo los ID de usuario y grupo con los permisos de cada archivo. Como esos ID viajan dentro del comando, un cliente podría falsificarlos, pero FADU dice que cierra ese hueco con autenticación basada en capacidades. Cada comando lleva una capacidad emitida por un servidor de autenticación externo, más un código calculado con una clave que solo comparten ese servidor y el disco. Esto no aparece detallado en el material publicado. FADU agrega que tiene planificado soportar el protocolo de autenticación Kerberos. En los discos conectados por red se usan las protecciones estándar de NVMe-oF, que solo admiten hosts aprobados de antemano. Un disco confía en el kernel de un único host, como cualquier disco NVMe.
Según lo que FADU describió a Tom's Hardware, las ACL y otras funciones faltan en la versión actual, salvo el cifrado, que en este caso maneja el soporte estándar de disco autocifrado TCG Opal del FC6161. Los cortes de energía se manejan como es habitual, con condensadores que vacían los metadatos, el búfer de escritura y un registro de las operaciones en curso. Al reiniciar, el disco vuelve a ejecutar las operaciones que quedaron pendientes, y toda escritura que el disco confirma queda guardada.
¿Qué viene después?
FADU apunta a largo plazo a una solución de almacenamiento JBoF sin servidor al frente, con FS-SSD, un switch PCIe y una DPU o tarjeta de red que maneje NVMe-oF en hardware. El modelo de FADU calcula cerca de 42% menos consumo y alrededor de 57% menos costo por servidor de 16 discos, más densidad por rack y un costo total de propiedad a cinco años bastante menor. Los discos se ubicarían detrás de los servidores de metadatos pNFS existentes y podrían escalar. Los controladores de FADU ya van en discos como el SN861, que lanzó Western Digital y hoy vende SanDisk, pero esto ampliaría las opciones y soluciones que puede ofrecer.
| Hito | Plazo, según FADU | Detalle |
|---|---|---|
| Resultados en host Gen6 | Antes del primer trimestre de 2027 | FS-SSD probado en un host PCIe 6.0, con las cifras de amplificación de escritura en hardware |
| Muestras para socios | Tercer trimestre de 2027 | Las conversaciones con OEM y ODM están en etapa temprana y se espera colaboración activa cuando salgan las muestras |
| JBoF sin host | Antes de fines de 2027 | Diseño de referencia sobre DPU E1 de Xsight Labs, entregado a socios OEM y ODM |
| Acceso desde GPU | Hoy, con GPUDirect Storage | Funciona con GDS a través del cliente de kernel. FADU planea sumarse al Accelerated IO SIG (xio-sig), donde Nvidia liberó cuFile, sin trabajo directo con Nvidia |
| Estándares | Nada presentado aún | FADU planea abrir una discusión sobre un set de comandos con semántica de archivos en NVM Express y OCP Storage, después de las muestras y el código de cliente |
El próximo año deberían llegar cifras reales y muestras, además del diseño de referencia JBoF. Más adelante podría aparecer una propuesta en NVM Express u OCP Storage para un set de comandos con semántica de archivos que consolide el enfoque. Para Tom's Hardware, FADU tiene una buena idea, la construye sobre un marco existente y cuenta con un banco de pruebas con resultados, un camino en hardware sobre su controlador Gen6 y un modelo de confianza pensado. Lo que falta ahora es una corrida en un host Gen6 que respalde sus afirmaciones.





