FADU's FS-SSD embeds the filesystem inside SSD flash and carries NFSv3 file operations within NVMe commands, letting GPUs, DPUs and NICs read files without a host file system.
SSD controller designer FADU announced its new File-Semantic SSD (FS-SSD) at the 2026 OCP Global Summit. The device moves the file system into the SSD itself. According to a white paper, this lets GPUs, DPUs, and NICs 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 that it expects partner samples by Q3 2027.
FADU is a fabless SSD controller designer based in Seoul, South Korea. Its FS-SSD technology is designed to handle the control path, since the data path moved to accelerators years ago. FADU's measurements show that the file system and block layers can consume about 30% of CPU cycles in a GPUDirect Storage (GDS) random-read workload. The company notes that bypass options give up on files, and it claims its solution offers the best of both worlds.
In FADU's preliminary Network File System (NFS) over NVMe test, a drive built on its FC6161 Gen6 controller in a PCIe 5.0 host maintained remote file throughput as the server scaled down from what FADU labels 16 cores to just one, sustaining about 460,000 ops/s. FS-SSD holds about 460,000 ops/s from 16 server cores down to one, while NFS over RDMA falls from approximately 150,000 to 40,000 ops/s. (Image credit: FADU)
FADU chose NFSv3 because it is "small (21 operations), OS- and filesystem-agnostic, and stateless," with low firmware overhead. The NFSv3 operations are carried inside standard NVMe commands, and the drive handles path lookup, access control, and file-to-flash mapping. FS-SSD supports PCIe today, and NVMe-oF over RDMA and TCP work without any new transport. 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 natural flash pages and with sections at corresponding erase units, so the F2FS node table becomes a "File Map" that points node IDs to physical flash addresses.
A major advantage is that the DRAM overhead for mapping metadata is considerably smaller. The drive uses the same amount of DRAM as a standard SSD, about 0.1% of NAND capacity (roughly 1 GB per TB), which a standard SSD fills almost entirely with its mapping table. In FS-SSD, about 95% of that DRAM can act as a hot-path node cache.
The design also replaces two garbage collectors with one, avoiding what FADU calls the "double GC" of host F2FS, in which file-system cleanup and the drive's own garbage collection amplify each other. The company said write amplification is 63% lower than a host F2FS solution on a mixed sequential and random workload using FADU's research prototype. 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 this is not a hardware result.
Most importantly, the approach 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 place commands in the drive's submission queue. Data travels from the SSD to the NIC via PCIe peer-to-peer DMA and leaves as RDMA writes. FADU's named use cases include GPU file reads and checkpoints, DPU-served HTTP content delivery, and a JBoF (just a bunch of flash) file server.
FADU's internal test numbers come from a client and server built on an 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 tests were run with fio, comparing baseline F2FS and Ext4 on block firmware against FS-SSD through a kernel client and an SPDK user-space client. The sequential test used 1 thread, queue depth (QD) 128, and 128KB blocks. The random test used 4 threads, QD128, and 4KB blocks. These block sizes are typical for client workloads, so they are a fair measure. Preliminary results are shown below.
Compared with SPDK on the raw drive (figures FADU provided to us), FS-SSD's SPDK client retains about 93% of performance on 4K random read and 53% on 4K random write, measured with fio. That implies a cost of about 7% and 47%, respectively, for the in-drive file layer. The raw drive's 13,240 MB/s random write exceeds the roughly 12 GB/s FADU cites as the NAND's program bandwidth, but those runs likely did not reach steady state. The Filebench result is particularly interesting, because the SPDK random gains also apply to a plain block device. This should be the workload most favorable to the technology. The Filebench file server is metadata-heavy with relatively high host overhead. FADU says it used 10,000 files in a multi-level tree, a mean directory width of 20, a mean file size of 128KB, and 50 client threads.
**FADU's preliminary fio results: Gen6 controller in a PCIe 5.0 host, direct I/O**
| Configuration | Sequential read (MB/s) | Sequential write (MB/s) | 4KB random read (MB/s) | 4KB random write (MB/s) |
|---|---|---|---|---|
| F2FS | 14,120 | 4,510 | 7,850 | 3,980 |
| Ext4 | 14,130 | 7,050 | 9,120 | 4,560 |
| FS-SSD (kernel client) | 14,140 | 11,940 | 8,070 | 4,320 |
| FS-SSD (SPDK client) | Not reported | Not reported | 13,000 | 7,030 |
| Raw block (SPDK) | Not reported | Not reported | 13,990 | 13,240 |
It is important to note that although this test uses a Gen6 drive, the host is PCIe 5.0. As a result, every sequential read configuration tops out at around 14.1 GB/s, which is roughly the link limit. The testbed also uses a consumer-class desktop CPU, and the one-core NFS server is a showcase example. By our calculations, the kernel client trails Ext4 by 11.5% on random read and 5.3% on random write.
More generally, a difficult question is how concurrent GPU, DPU, and host writers coordinate, and how a kernel mount's page cache stays coherent with GPU access. Under the pNFS Flexible File Layout specification (RFC 8435), NFSv3 storage devices are "always treated as loosely coupled," which means "Mandatory byte-range locking cannot be supported."
Credentials carried in the NVMe command also raise security concerns. 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 does not describe features such as snapshots, encryption handling, quotas, ACLs, or crash handling. Statelessness is what makes the design work, but it does not solve every problem, so the trust burden shifts elsewhere.
In response to our questions, FADU said there is no cross-host locking, because NFS's lock manager is not implemented. The drive applies each write whole and in order. If two writes hit the same location, the second one wins, a behavior FADU calls "last-writer-wins." Coordination depends on the clients. Kernel-mounted clients get the usual advisory locks among themselves, GPU and SPDK clients coordinate within the application, and at scale a pNFS metadata server handles coordination. Caching is handled like ordinary NFS for kernel clients, and is not done at all for GPU and SPDK clients. FADU said this is stock NFSv3 behavior.
The drive must check user and group IDs against file permissions itself. Because those IDs travel inside the command, a client could forge them. FADU says it closes this gap with capability-based authentication. Each command carries a capability issued by an external authentication server, plus a code computed with a key shared only between that server and the drive. This is not detailed in FADU's published material. FADU adds that support for the Kerberos authentication protocol is planned. For networked drives, standard NVMe-oF protections apply, and only pre-approved hosts are admitted. A drive trusts a single host's kernel the way any NVMe drive does.
However, as FADU explained to us, ACLs and other features are missing from the current release. Encryption is the exception, and in this case it is handled by the FC6161's standard TCG Opal self-encrypting drive support. Power loss is typically handled with capacitors that flush metadata, the write buffer, and a log of in-flight operations. On restart, the drive replays unfinished operations, and any write the drive has acknowledged is durable.
FADU's longer-term goal is a JBoF storage solution with no server in front, consisting of FS-SSDs, a PCIe switch, and a DPU or NIC that handles NVMe-oF in hardware. FADU's model projects about 42% lower power, about 57% lower cost per 16-drive server, higher rack density, and 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 in drives such as the SN861, which Western Digital launched and SanDisk now sells, and FS-SSD would expand the options and solutions the company can offer.
**FADU's FS-SSD roadmap**
| Milestone | Timing (per FADU) | Details |
|---|---|---|
| Gen6-host results | By Q1 2027 | FS-SSD tested in a PCIe 6.0 host; hardware write-amplification figures to follow |
| Partner samples | Q3 2027 | OEM/ODM talks are at an early stage; active collaboration expected once samples ship |
| Hostless JBoF | By end of 2027 | Reference design built on Xsight Labs E1 DPUs, delivered to OEM/ODM partners |
| GPU access | Now, via GPUDirect Storage | Works with GDS through the kernel client; FADU intends to join the Accelerated IO SIG (xio-sig), where Nvidia open-sourced cuFile; no direct engagement with Nvidia |
| Standards | Nothing submitted yet | FADU plans to start a file-semantic command set discussion at NVM Express and OCP Storage; samples and client code come first |
Next year should bring real numbers and samples, and the JBoF reference design is also expected. A proposal to NVM Express or OCP Storage for a file-semantic command set may follow, which would help solidify and mature the approach. FADU has a sound concept, 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.