Introduction to FS-SSD
SSD controller designer FADU's new File-Semantic SSD (FS-SSD) was announced at the 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 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 random-read workload. It notes that bypass options give up the files, and the company claims its solution promises the best of both worlds.
Performance and Architecture
In FADU's own preliminary Network File System 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 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 expects Gen6-host results by Q1 2027, with partner samples in Q3 2027.
FADU chooses to use NFSv3 because it is small with 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. 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 erase units, turning the F2FS node table into a File Map pointing node IDs at physical flash addresses.
Metadata and Garbage Collection
One big advantage is that the DRAM mapping metadata overhead is considerably smaller, using the same amount of DRAM as a standard SSD at approximately 0.1% of NAND capacity, about 1 GB per TB. Here, most of that DRAM, roughly 95%, can act as a hot-path node cache.
One garbage collector also replaces two, avoiding 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. FADU noted 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.
Host-Free Access and Use Cases
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 file server.
Testbed Configuration and Results
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 128, with 128KB blocks, while random is at 4 threads, the same queue depth, but with 4KB blocks.
Against SPDK on the raw drive, figures FADU provided show that 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.
This should be the workload most favorable for the technology, as the Filebench file server is metadata-heavy with relatively high host overhead, using 10,000 files in a multi-level tree, a mean directory width of 20, a mean file size of 128KB, and 50 client threads.
Because this test is on a Gen6 drive using a PCIe 5.0 host, 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.
A notable challenge involves how concurrent GPU, DPU, and host writers coordinate, and how a kernel mount's page cache stays coherent with GPU access. NFSv3 storage devices, by the pNFS Flexible File Layout spec, are always treated as loosely coupled, meaning 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 basic NFS schemes where 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, and crash handling.
In reply to inquiries, FADU stated 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 using a last-writer-wins approach. Coordination depends on the clients, and caching is handled like ordinary NFS or omitted entirely for GPU and SPDK clients.
The drive checks user and group IDs against file permissions itself. Because those IDs ride inside the command, a client could potentially fake them, but FADU addresses this issue with capability-based authentication. Each command carries a capability issued by an outside authentication server, plus a code computed with a shared key. Support for the Kerberos authentication protocol is also planned.
ACLs and other advanced features are missing in the current release, aside from encryption, which is handled by the FC6161's standard TCG Opal self-encrypting drive support. Power loss is typically handled with capacitors flushing metadata, the write buffer, and a log of in-flight operations to ensure durability upon restart.
FADU's long-term goal is to produce a JBoF storage solution with no server in front, combining FS-SSDs, a PCIe switch, and a DPU or NIC for handling NVMe-oF in hardware. FADU's model suggests this configuration achieves about 42% lower power, about 57% lower cost per 16-drive server, and higher rack density with a significantly lower total cost of ownership.
The upcoming year is expected to bring real numbers, partner samples, and a JBoF reference design. An NVM Express or OCP Storage proposal may follow to establish a standardized file-semantic command set. A true Gen6-host run is now required to fully substantiate the company's performance claims.
