FADU sviluppa FS-SSD per portare le operazioni sui file nell’SSD

FADU sta sviluppando FS-SSD, un’architettura che porta la gestione dei file nell’unità di archiviazione: l’SSD riceve operazioni NFSv3 attraverso comandi NVMe standard e gestisce al suo interno funzioni come ricerca dei percorsi e mappatura dei dati. Il vantaggio senza passare dal file system dell’host riguarda specifici percorsi di accesso diretto; un client kernel continua invece a usare software del sistema host.

Come FS-SSD gestisce i file nell’SSD

FS-SSD porta nell’unità operazioni che normalmente vengono gestite dal sistema operativo. FADU incapsula le operazioni NFSv3, il protocollo per accedere ai file in rete, in comandi NVMe standard: GPU, DPU e NIC compatibili possono così richiedere file per nome. Il progetto prevede il trasporto su PCIe e NVMe-oF tramite RDMA o TCP.

All’interno dell’unità, il livello dedicato ai file deriva da F2FS ed è progettato insieme al flash translation layer (FTL), che traduce gli indirizzi logici in posizioni nella memoria flash e ne gestisce l’organizzazione. La co-progettazione combina attività di mappatura e raccolta dei dati da cancellare che nei sistemi convenzionali sono separate. FADU stima una DRAM per i metadati pari a circa lo 0,1% della capacità NAND, cioè circa 1 GB per terabyte; circa il 95% di questa memoria può essere usato come cache dei nodi consultati più spesso.

Accesso diretto e client kernel seguono percorsi diversi

L’accesso diretto descritto da FADU può evitare il percorso del file system dell’host: GPU, DPU o NIC inviano comandi NVMe all’unità. Un client kernel, invece, passa dal kernel del sistema host e continua a richiedere software e lavoro della CPU host.

Questo cambia il modo di leggere i benchmark: i risultati di un client SPDK non descrivono automaticamente le prestazioni del client kernel. La differenza tra i due percorsi è importante anche per interpretare il risultato Filebench di FADU, che riguarda operazioni su file in accesso remoto.

Che cosa misurano i risultati preliminari di FADU

Nel white paper del 12 ottobre 2026, FADU riporta circa 460.000 operazioni al secondo in una prova preliminare Filebench con un controller FC6161 Gen6 collegato a un host PCIe 5.0. Il risultato resta vicino a quel livello mentre i core assegnati al server scendono da 16 a uno. Nel confronto di FADU, Linux NFS-over-RDMA passa invece da circa 150.000 operazioni al secondo con 16 core a circa 40.000 con un core.

La prova usava un carico da file server con 10.000 file in una struttura di directory a più livelli e 50 thread client. La configurazione descritta da FADU comprendeva processori Intel Core i5-13600K, 128 GB di DDR5 e una scheda di rete Mellanox ConnectX-6 da 100 Gbps. Sono misurazioni preliminari comunicate dall’azienda, non risultati ottenuti su un host PCIe 6.0.

FADU riferisce inoltre una riduzione del 63% della write amplification, cioè dei dati scritti nella memoria flash rispetto ai dati richiesti, rispetto a F2FS sull’host con un carico misto sequenziale e casuale. La prova del prototipo è stata eseguita con NVMeVirt, un emulatore software di SSD, non su un’unità fisica.

I valori fio di I/O casuale a blocchi da 4 KB riportati da FADU mostrano anche quanto conti il tipo di client. La tabella riporta lettura e scrittura in MB/s nelle cinque configurazioni confrontate:

Per calcolo sui valori comunicati da FADU, il client SPDK di FS-SSD raggiunge circa 1,43 volte il risultato di Ext4 in lettura casuale a 4 KB e 1,54 volte in scrittura. Nel client kernel, invece, i valori di FS-SSD sono inferiori a quelli di Ext4 per entrambe le operazioni. Il risultato di scrittura a blocchi grezzi, 13.240 MB/s, supera la banda di programmazione NAND di circa 12 GB/s citata da FADU; Tom’s Hardware segnala che potrebbe non rappresentare una prestazione a regime.

Scritture concorrenti e funzioni di sicurezza

La versione descritta non implementa il locking tra host. Se due host scrivono nella stessa posizione, le scritture vengono applicate interamente e in ordine, e quella successiva prevale. Per i client GPU e SPDK, il coordinamento deve quindi avvenire nell’applicazione; un server di metadati pNFS può gestirlo su scala più ampia. I client kernel mantengono i consueti lock consultivi tra loro.

Secondo quanto riportato da Tom’s Hardware, FADU descrive l’autenticazione tramite capacità rilasciate da un server esterno e indica il supporto Kerberos come previsto. Il resoconto segnala inoltre che ACL e altre funzioni dei file system non sono presenti nella versione descritta. Il controller FC6161 supporta la cifratura autonoma TCG Opal.

Roadmap e stime per il modello JBoF

La roadmap FADU riportata da Tom’s Hardware fissava come obiettivi risultati su host Gen6 entro il primo trimestre 2027, campioni per i partner nel terzo trimestre 2027 e un progetto di riferimento JBoF senza host entro la fine del 2027. Il progetto JBoF indica una piattaforma basata su DPU Xsight Labs E1.

Per questa architettura proposta, il modello FADU stima circa il 42% di potenza in meno e il 57% di costo in meno per server da 16 unità, una densità rack di circa 1,7 volte e un costo totale di proprietà (TCO) quinquennale inferiore di circa il 60%. Sono proiezioni del modello aziendale, non risultati operativi misurati.