FADU développe FS-SSD, un SSD qui gère les fichiers en interne

FADU développe FS-SSD, une architecture qui traite les opérations sur les fichiers dans le SSD et les transmet sous forme de commandes NVMe standard. Son livre blanc du 12 octobre 2026 décrit une voie d’accès direct conçue pour éviter le passage par le système de fichiers de l’hôte. Les résultats de performance publiés par FADU sont préliminaires, et le client monté via le noyau continue de s’appuyer sur le logiciel de l’hôte.

Comment FS-SSD traite les fichiers dans le SSD

FS-SSD associe des opérations NFSv3 à des commandes NVMe standard. Le SSD prend en charge la recherche de chemins, le contrôle d’accès, l’association des fichiers à la mémoire flash, l’allocation et le ramasse-miettes, qui libère les blocs de mémoire flash devenus inutiles. NFSv3 regroupe 21 opérations ; FADU indique que leur intégration aux commandes NVMe évite de créer un nouveau protocole de transport.

La couche fichiers de FS-SSD s’inspire de F2FS et a été conçue avec la couche de traduction flash (FTL), qui gère la correspondance entre les données logiques et la mémoire NAND. FADU décrit cette conception comme une manière de rapprocher la gestion des fichiers et celle de la mémoire flash. Le système prévoit environ 0,1 % de la capacité NAND en DRAM, soit près de 1 Go par téraoctet ; selon FADU, environ 95 % de cette mémoire peut servir de cache pour les métadonnées fréquemment utilisées.

Deux voies d’accès aux fichiers avec FS-SSD

Dans la voie directe décrite par FADU, un GPU, un DPU ou une carte réseau intelligente (SmartNIC) peut envoyer des commandes NVMe au SSD pour accéder aux fichiers. Cette voie vise à contourner le système de fichiers de l’hôte. Un client monté via le noyau fonctionne autrement : il utilise toujours le logiciel de l’hôte et conserve une charge de traitement côté noyau.

La différence compte surtout pour les traitements qui accèdent directement au stockage depuis un accélérateur. Une application utilisant le client noyau reste, elle, tributaire du chemin logiciel de l’hôte. Le contournement annoncé par FADU dépend donc du mode d’accès employé.

Ce que mesurent les premiers résultats de FADU

Dans son livre blanc du 12 octobre 2026, FADU rapporte environ 460 000 opérations par seconde dans un test Filebench distant, avec un contrôleur FC6161 Gen6 installé sur un hôte PCIe 5.0. Le débit reste proche de cette valeur lorsque le nombre de cœurs alloués au serveur passe de 16 à un. À titre de comparaison, le système Linux NFS sur RDMA indiqué par FADU passe d’environ 150 000 opérations par seconde avec 16 cœurs à environ 40 000 avec un seul.

Le scénario Filebench simule un serveur de fichiers : il comprend 10 000 fichiers répartis dans une arborescence à plusieurs niveaux, 50 threads clients et une taille moyenne de fichier de 128 Ko. La mesure provient de FADU. Elle décrit cette charge et cette configuration précises.

FADU a également publié des résultats préliminaires de débit pour des accès aléatoires de 4 Ko. Le tableau compare les configurations pour cette même charge, en mégaoctets par seconde convertis en mégaoctets français (Mo/s) :

À partir des chiffres communiqués par FADU, le client SPDK de FS-SSD atteint environ 1,43 fois le débit d’Ext4 en lecture aléatoire de 4 Ko et 1,54 fois en écriture. Ce sont des rapports calculés à partir des résultats de FADU, pas des mesures distinctes. Le client noyau de FS-SSD affiche, pour ces deux opérations, des valeurs inférieures à celles d’Ext4 dans le même tableau.

Le résultat de 13 240 Mo/s en écriture aléatoire pour SPDK en accès bloc brut dépasse les quelque 12 Go/s de bande passante de programmation NAND cités par FADU. Il peut ne pas correspondre à un régime stabilisé. Ces chiffres décrivent des mesures préliminaires sur un hôte PCIe 5.0, avec un contrôleur Gen6 FC6161.

Écritures concurrentes et sécurité

L’implémentation décrite ne fournit pas de verrouillage entre hôtes. Si plusieurs hôtes écrivent au même emplacement, les écritures sont appliquées dans l’ordre et la dernière l’emporte. Les clients GPU et SPDK doivent organiser la coordination au niveau de l’application ; un serveur de métadonnées pNFS peut aussi la prendre en charge à grande échelle.

FADU décrit une authentification fondée sur des capacités et prévoit une prise en charge de Kerberos. Le contrôleur FC6161 prend en charge le chiffrement automatique TCG Opal. Les listes de contrôle d’accès, ou ACL, font partie des fonctions absentes de la version décrite.

Les objectifs de FADU pour 2027

La feuille de route de FADU vise des résultats sur hôte Gen6 d’ici le premier trimestre 2027, des échantillons destinés à des partenaires au troisième trimestre 2027 et une conception de référence JBoF sans hôte d’ici la fin de 2027. Cette dernière doit s’appuyer sur les DPU Xsight Labs E1.

Pour cette architecture proposée, le modèle de FADU estime une baisse d’environ 42 % de la consommation électrique et de 57 % du coût par serveur de 16 disques. Il prévoit aussi une densité en rack environ 1,7 fois supérieure et un coût total de possession (TCO) inférieur d’environ 60 % sur cinq ans. Ce sont des estimations de modèle, pas des résultats mesurés en exploitation.