FADU puts the filesystem inside the SSD's flash to bypass host CPUs

SSD controller designer FADU’s new File-Semantic SSD (FS-SSD) was announced at the 2026 OCP Global Summit. The new device promises to move the file system into the SSD itself. As detailed in a white paper, this enables GPUs, DPUs, and NICs to open and read files with “no host filesystem, no block layer, and no storage-server CPU in the path.” FADU told Tom’s Hardware Premium it expects partner samples by Q3 2027.

FADU is a Seoul, South Korea-based fabless SSD controller designer. Its FS-SSD technology is designed to handle and improve the control path, as the data path side moved to accelerators years ago. FADU’s measurements show that the file system, plus block layers, can consume about 30% of CPU cycles in a GPUDirect Storage (GDS) random-read workload. It notes that bypass options give up the files, and the company claims its solution promises the best of both worlds.

In FADU’s own preliminary Network File System (NFS) over NVMe test, on a drive built on its FC6161 Gen6 controller in a PCIe 5.0 host, remote file throughput held steady as the server downshifted from what FADU labels 16 cores to just one, maintaining about 460,000 ops/s.

The NFSv3 operations are carried inside standard NVMe commands, and the drive handles path lookup, access control, and file-to-flash mapping. FS-SSD’s performance is remarkable when compared to Linux NFS-over-RDMA, which achieved a third of the ops/s with 16 cores and only 40K ops/s with one core. The technology remains “under active development,” and FADU told Tom’s Hardware Premium it expects Gen6-host results by Q1 2027, with partner samples in Q3 2027.

FADU chooses to use NFSv3 because it’s “small (21 operations), OS- and filesystem-agnostic, and stateless” with low firmware overhead. FS-SSD supports PCIe today, with NVMe-oF over RDMA and TCP working without any new transport needed. Reusing an existing protocol is a smart move, in our view. Under the hood, the file system and flash translation layer are merged with a file layer derived from F2FS. Node and data blocks are aligned with the natural flash pages, sections at corresponding erase units, so that the F2FS node table becomes a “File Map” pointing the node IDs at physical flash addresses.

One big advantage is that the DRAM mapping metadata overhead is considerably smaller: it uses the same amount of DRAM as a standard SSD, ~0.1% of NAND capacity (about 1 GB per TB), which a standard SSD fills almost entirely with its mapping table. Here, most of that DRAM, ~95%, can act as a hot-path node cache.

One garbage collector also replaces two, avoiding what FADU calls the “double GC” of host F2FS, where file-system cleanup and the drive’s own garbage collection amplify each other. Write amplification is also 63% lower versus a host F2FS solution on a mixed sequential and random workload with FADU’s research prototype, the company said. FADU told Tom's Hardware Premium that the prototype runs synthetic fio workloads on NVMeVirt, an open-source software SSD emulator from Seoul National University, so it is not a hardware result.

Most importantly for this method, it ensures host-free access. The GPU builds NFS-over-NVMe commands in queues in its own memory, which could include HBM. Alternatively, a remote SmartNIC or DPU with NVMe-oF target offload can drop commands in the drive’s submission queue. The data goes from SSD to NIC via PCIe peer-to-peer DMA, coming out as RDMA writes. FADU’s explicitly named use cases for this include GPU file reads and checkpoints, DPU-served HTTP content delivery, and a JBoF (just a bunch of flash) file server.

FADU’s numbers for its internal test come from a client and server Intel Core i5-13600K, a CPU with 20 threads that clocks up to 5.1 GHz with 128GB of DDR5, and a Mellanox ConnectX-6 100 Gbps NIC. Synthetic testing is compared using fio with the baseline F2FS and Ext4 on block firmware versus the FS-SSD via a kernel client and an SPDK user-space client. The sequential test is 1 thread, queue depth (QD) 128, with 128KB blocks, while random is at 4 threads, the same QD128, but with 4KB blocks.

These block sizes are typical for client workloads in our experience, so they are a fair measure, with detailed preliminary results in the table below. Against SPDK on the raw drive, figures FADU provided to us, FS-SSD’s SPDK client keeps about 93% on 4K random read and 53% on 4K random write, via fio, with around a 7% and 47% cost for the in-drive file layer. Though the raw drive’s 13,240 MB/s random write is above the ~12 GB/s FADU gives as the NAND’s program bandwidth, those runs likely weren’t at steady state. The Filebench result is particularly interesting, as the SPDK random gains apply to a plain block device too.

This should be the workload most favorable for the technology, as the Filebench file server is metadata-heavy with relatively high host overhead: FADU says it uses 10,000 files in a multi-level tree, mean directory width 20, and a mean file size of 128KB with 50 client threads.

One important thing to recall is that although this test is on a Gen6 drive, the test results are on a PCIe 5.0 host. Therefore, every sequential read config tops out at around 14.1 GB/s, which is roughly the link limit. The testbed also uses a consumer-class desktop CPU, while the one-core NFS server is a showcase example. The kernel client ends up 11.5% behind Ext4 on random read and 5.3% behind on random write, again by our math.

One example of a tough question more generally is: how do concurrent GPU, DPU, and host writers coordinate? How does a kernel mount’s page cache stay coherent with GPU access? NFSv3 storage devices, by the pNFS Flexible File Layout spec (RFC 8435), are “always treated as loosely coupled,” which means “Mandatory byte-range locking cannot be supported.”

Credentials riding in the NVMe command may also face security issues, as loosely coupled devices get only “a level of security equivalent to AUTH_SYS,” NFS’s basic scheme, in which the server trusts whatever user and group IDs the client sends. FADU’s published material also does not describe features such as snapshots, encryption handling, quotas, ACLs, crash handling, and so forth, related to this. Statelessness is what makes it work, but it doesn’t solve all problems, so the trust factor moves elsewhere.

In reply to our questioning, FADU said that there is no cross-host locking, as NFS’s lock manager isn’t implemented. The drive applies each write whole, in order. If two writes hit the same spot, the second one wins; this is “last-writer-wins.” Coordination depends on the clients: kernel-mounted ones get the usual advisory locks among themselves, GPU and SPDK clients coordinate in the application, and at scale a pNFS metadata server handles the coordination. Caching is also handled like ordinary NFS, with kernel clients, or is not done at all, for GPU and SPDK clients. This is stock NFSv3 behavior.

The drive has to check user/group IDs against the file permissions itself. Because those IDs ride inside the command, a client could fake them, but FADU says it closes that issue with capability-based authentication. Each command carries a capability issued by an outside authentication server, plus a code computed with a key shared only between that server and the drive. This is not detailed in its published material. FADU adds that support for the Kerberos authentication protocol is planned. For networked drives, the standard NVMe-oF protections are used, with only pre-approved hosts admitted. A drive trusts a single host’s kernel like any NVMe drive.

However, as FADU described to us, ACLs and other features are missing in the current release, aside from encryption, which in this case is handled by the FC6161’s standard TCG Opal self-encrypting drive support. Power loss is also typically handled with capacitors flushing metadata, the write buffer, and a log of in-flight operations. On restart, the drive replays the unfinished operations, and every write is durable if the drive acknowledges it.

FADU’s longer sights are on producing a JBoF storage solution with no server in front: FS-SSDs, a PCIe switch, and a DPU or NIC for handling NVMe-oF in hardware. FADU’s model puts this at about 42% lower power, about 57% lower cost per 16-drive server, and higher rack density with significantly lower five-year total cost of ownership. The drives would slot in behind existing pNFS metadata servers and could scale. FADU’s controllers already ship with drives such as the SN861, which Western Digital launched and SanDisk now sells, but this would expand the options and solutions it can provide.

Next year should bring real numbers and samples, with the JBoF reference design also expected. There may be an NVM Express or OCP Storage proposal down the line for a file-semantic command set to further cement and mature the approach. FADU has a good idea, is building it on an existing framework, and has a testbed with results and a hardware path forward on its Gen6 controller, with a trust model in mind. A Gen6-host run is now needed to support the company’s claims.