FADU FS-SSD Offloads NFS File Processing to Gen6 Drives, but Benchmarks Have Caveats

What FADU actually announced​

FADU introduced the drive at the 2026 Open Compute Project Global Summit in San Jose. The company says an FS-SSD manages files directly instead of block addresses. File processing firmware on its Gen6 controller performs file search, permission and file-to-address translation inside the SSD. The server's CPU and operating system have traditionally done that work.

The mechanism is deliberately conventional:

• FADU carries NFSv3 operations inside standard NVMe commands. The drive does path lookup, access checks and mapping to flash.
• Because the requests ride in standard NVMe commands, GPUs, DPUs and remote servers can read and write files directly.
• PCIe works today. NVMe-oF over RDMA and TCP should work without a new transport.
• FADU picked NFSv3 because it's small (21 operations), OS- and filesystem-agnostic and stateless, which keeps firmware overhead low.

Inside the drive, the filesystem and flash translation layer are merged. The file layer is derived from F2FS. The F2FS node table becomes a "File Map" that points node IDs at physical flash addresses. That removes the "double garbage collection" problem, where host F2FS cleanup and the SSD's own garbage collection amplify each other.

For a GPU, the path works like this:

1. The GPU builds NFS-over-NVMe commands in queues in its own memory, which can include HBM.
2. Alternatively, a SmartNIC or DPU with NVMe-oF target offload submits commands to the drive.
3. Data moves from the SSD to the NIC by PCIe peer-to-peer DMA and leaves as RDMA writes.

FADU names GPU file reads and checkpoints, DPU-served HTTP content delivery and a JBoF ("just a bunch of flash") file server as intended uses.

Not much of this touches a typical Windows PC. The pitch is for AI infrastructure, where, according to FADU, the approach could reduce CPU, memory, software and power demands. Nothing in the evidence suggests a benefit for ordinary desktop storage.

The numbers, and how far to trust them​

All of the following figures are FADU's own, from preliminary tests.

• CPU tax: FADU says the filesystem plus block layers can eat about 30% of CPU cycles in a GPUDirect Storage random-read workload.
• NFS scaling: The drive held about 460,000 ops/s as the server dropped from 16 cores to one. Linux NFS-over-RDMA fell from about 150,000 to 40,000 ops/s over the same range.
• DRAM: The drive uses about the same DRAM as a normal SSD, roughly 0.1% of NAND capacity (about 1 GB per TB). Because it needs less for a block mapping table, about 95% can serve as a hot-path node cache.
• Write amplification: FADU reports 63% lower than host F2FS on a mixed workload. This came from synthetic fio runs on NVMeVirt, an open-source SSD emulator, so it is not a hardware result.

The fio results below come from a Gen6 controller in a PCIe 5.0 host, in MB/s.

Several caveats apply:

• The host link caps the read numbers. Every sequential read tops out near 14.1 GB/s. That is the PCIe 5.0 limit, so these results say nothing about PCIe 6.0 throughput.
• The testbed is modest. Client and server were Intel Core i5-13600K desktops with 128 GB of DDR5 and a 100 Gbps ConnectX-6 NIC. A one-core NFS server is a showcase scenario, not a production design.
• The file layer has a cost. Against raw SPDK, the FS-SSD SPDK client keeps about 93% of 4K random-read throughput and 53% of random-write throughput.
• The kernel client trails Ext4 on random I/O. By Tom's Hardware's math, it is about 11.5% behind on random reads and 5.3% behind on random writes. It is well ahead of both filesystems on sequential writes.
• The raw random-write figure looks too high. The 13,240 MB/s result is above the roughly 12 GB/s FADU cites for NAND program bandwidth. Tom's Hardware suggests those runs probably weren't at steady state.

The sequential-write gain is the clearest win here. Tom's Hardware calls the metadata-heavy Filebench file-server test the workload most favorable to the technology. That suggests the gains are largest where host overhead dominates.

The hard questions: locking, security and features​

Putting a filesystem in firmware moves trust and coordination somewhere new. FADU's answers, as given to Tom's Hardware, are mixed.

Locking. There is no cross-host locking because the NFS lock manager isn't implemented. The drive applies each write whole and in order, and if two writes hit the same spot, the later one wins. Clients coordinate:

• Kernel-mounted clients use advisory locks among themselves.
• GPU and SPDK clients coordinate in the application.
• At scale, a pNFS metadata server does the coordination.

That fits the pNFS Flexible File Layout standard, RFC 8435. It treats NFSv3 and NFSv4.0 storage devices as loosely coupled. Under that model, mandatory byte-range locking cannot be supported because the storage device can't distinguish I/O by lock owner.

Security. User and group IDs ride inside the commands, so a client could forge them. RFC 8435 says the loosely coupled model can't protect against malicious clients and gives security equivalent to AUTH_SYS. FADU says it closes the gap with capability-based authentication:

• Each command carries a capability issued by an external authentication server.
• It also carries a code computed with a key shared only between that server and the drive.
• Kerberos support is planned.
• For networked drives, standard NVMe-oF protections apply, and only pre-approved hosts are admitted.

FADU's published material doesn't detail this mechanism, so treat it as a company explanation and not a reviewed design. One outside analysis raised the obvious governance worries. Those include how ACL updates propagate to drives and what happens if firmware is compromised. That is commentary, not a finding about FADU's design. Still, firmware that enforces permissions is firmware that needs auditing.

Missing features. ACLs and other features are absent in the current release. Encryption relies on the FC6161's standard TCG Opal support. Power-loss handling uses capacitors to flush metadata, the write buffer and a log of in-flight operations. On restart, the drive replays unfinished operations, and FADU says every acknowledged write is durable. Snapshots and quotas aren't described.

The hardware around it​

Coverage from The Korea Times confirms the broader picture. FADU demonstrated its FC6161 controller with a 16-terabyte SSD at the summit. The complete Gen6-based SSD draws under 28 watts during sequential writes and under 5 watts in standby. The same report cites performance up to 2.5 times FADU's previous-generation Gen5 technology. Separately, FADU has said it completed its PCIe Gen6 controller and plans full-scale sales by year-end. That is a separate matter from FS-SSD availability.

Roadmap​

FADU's long-term target is a hostless JBoF server made of FS-SSDs, a PCIe switch and a DPU or NIC. Its model projects about 42% lower power and about 57% lower cost per 16-drive server. Those are projections, not measured deployments. FADU also says it has no direct engagement with Nvidia, though it plans to join the Accelerated IO SIG.

Bottom line​

The idea is plausible and built on existing pieces. NFSv3, NVMe, F2FS lineage and pNFS are all familiar. The headline gain is real in FADU's tests: CPU-independent file serving, with a large sequential-write advantage. But the evidence is vendor-supplied and preliminary:

• The testbed is PCIe 5.0.
• The write-amplification claim comes from an emulator.
• Locking is last-writer-wins.
• The authentication scheme is undocumented.
• Standard features such as ACLs are missing.

Until the promised Gen6-host results arrive by Q1 2027, and until independent testers get samples, this is a promising architecture and not a proven product. Storage admins should file it under "watch," not "plan around."