A FADU desenvolve a FS-SSD, uma arquitetura que leva operações de arquivos para dentro da unidade: comandos NFSv3 são transportados em comandos NVMe padrão, e o próprio SSD cuida de tarefas como localizar arquivos e mapear dados para a memória flash. A proposta permite que certos acessos diretos de GPU, DPU ou placa de rede contornem o sistema de arquivos do host; um cliente montado pelo kernel ainda usa software do host.
Como a FS-SSD trata arquivos dentro do SSD
NFSv3 é um protocolo de rede para operações de arquivos; NVMe é a interface de comandos usada para acessar unidades de armazenamento. Na FS-SSD, a FADU encapsula operações NFSv3 nos comandos NVMe padrão, sem criar um novo protocolo de transporte. A empresa descreve suporte a PCIe e a NVMe-oF, que permite acesso remoto por RDMA ou TCP.
Dentro da unidade, uma camada de arquivos derivada do F2FS trabalha em conjunto com a camada de tradução flash (FTL). Essa integração reúne o tratamento de operações de arquivos e o mapeamento para a memória NAND, incluindo tarefas como alocação e coleta de lixo. A FADU estima que os metadados usem cerca de 0,1% da capacidade NAND, aproximadamente 1 GB por terabyte, e que cerca de 95% dessa DRAM possa funcionar como cache de nós acessados com frequência.
Duas rotas de acesso a arquivos na FS-SSD
A rota direta descrita pela FADU permite que uma GPU, DPU ou NIC envie comandos NVMe à unidade sem passar pelo sistema de arquivos do host. Já o cliente kernel oferece um ponto de montagem, mas continua usando o kernel e outros softwares do host.
O que os resultados preliminares da FADU medem
No white paper datado de 12 de outubro de 2026, a FADU relatou cerca de 460 mil operações por segundo em um teste remoto Filebench com o controlador Gen6 FC6161 instalado em um host PCIe 5.0. O resultado permaneceu próximo desse patamar quando a alocação do servidor caiu de 16 núcleos para um. Na comparação da empresa, o NFS sobre RDMA no Linux passou de cerca de 150 mil operações por segundo com 16 núcleos para cerca de 40 mil com um.
Para I/O aleatório de 4 KB, os resultados preliminares informados pela FADU foram:
| Configuração | Leitura aleatória de 4 KB (MB/s) | Gravação aleatória de 4 KB (MB/s) |
| F2FS | 7.850 | 3.980 |
| Ext4 | 9.120 | 4.560 |
| Cliente kernel da FS-SSD | 8.070 | 4.320 |
| Cliente SPDK da FS-SSD | 13.000 | 7.030 |
| SPDK em bloco bruto | 13.990 | 13.240 |
A partir desses valores informados pela FADU, o cliente SPDK da FS-SSD alcança cerca de 1,43× o resultado do Ext4 em leitura aleatória de 4 KB e 1,54× em gravação. O cliente kernel, por sua vez, fica abaixo do Ext4 nos dois resultados da tabela. São modos de acesso diferentes, por isso o resultado do cliente SPDK não descreve o desempenho do cliente kernel.
O número de 13.240 MB/s de gravação do SPDK em bloco bruto supera os cerca de 12 GB/s de largura de banda de programação NAND citados pela FADU e pode não representar desempenho sustentado. Em outro teste de protótipo, a empresa informou uma redução de 63% na amplificação de escrita em relação ao F2FS do host, numa carga mista sequencial e aleatória executada em emulação de software NVMeVirt.
Gravações simultâneas exigem coordenação
Na implementação descrita, não há bloqueio entre hosts. Se gravações conflitantes atingirem o mesmo local, elas são aplicadas por inteiro e em ordem; a última gravação prevalece. Clientes GPU e SPDK precisam coordenar esses acessos na aplicação, enquanto um servidor de metadados pNFS pode fazer a coordenação em escala.
A FADU descreve autenticação baseada em capabilities e prevê suporte a Kerberos. A implementação também não inclui ACLs, e o suporte de criptografia indicado é o TCG Opal do controlador FC6161.
Metas de desenvolvimento e projeções para JBoF
A FADU prevê divulgar resultados com host Gen6 até o primeiro trimestre de 2027, enviar amostras a parceiros no terceiro trimestre e concluir, até o fim de 2027, um projeto de referência JBoF sem host, baseado em DPUs Xsight Labs E1. São metas de desenvolvimento, não resultados concluídos.
Para essa arquitetura JBoF proposta, o modelo da FADU estima cerca de 42% menos consumo de energia e 57% menos custo por servidor de 16 unidades, além de densidade de rack aproximadamente 1,7× maior e custo total de propriedade 60% menor em cinco anos. Esses números são projeções do modelo da empresa.
