What the Fusion SMB benchmarks actually tell you

Fusion SMB is Tuxera’s Linux SMB server. On MLPerf, it read training data about 10x faster than Samba, the open-source SMB server for Linux, and kept 24 simulated accelerators fed. Here is a quick tour of the benchmark results before you dive into the full report.

Key takeaways

• When the file-sharing layer is the bottleneck in AI training, HPC, or media production, the protocol implementation matters more than the hardware underneath it.
• On a test setup with 400 Gb of available bandwidth, Fusion SMB reached 46.86 GB/s and saturated the network, while Samba reached 4.17 GB/s on the same hardware.
• On MLPerf 3D-UNet, Fusion SMB kept 24 simulated accelerators at or above the 90 percent utilization threshold, while Samba could not sustain a single one.
• Fusion SMB saved a 104.7 GB LLaMA3-8B checkpoint in 6.7 seconds, against 28.1 seconds for Samba.
• In a production IBM Storage Scale deployment, 4 Fusion SMB nodes replaced 11 Samba nodes and cut 3-year TCO by 30 to 35 percent.

The differences in benchmark numbers for Fusion SMB and the competition are not subtle. On a single test server, Fusion SMB measured more than 10 times faster than Samba and sustained twice as many accelerators as the next-best alternative. The complete results, methodology, and architectural reasoning are in the Fusion SMB benchmark report.

Benchmark report

Tuxera Fusion SMB benchmark report

The full report has the FIO and MLPerf results against Samba, NFSD, NFS Ganesha, and Windows Server, plus the 3-year TCO comparison from a real deployment.

Get the report

How the file-sharing layer became the bottleneck

For years, the transport protocol was a secondary consideration. The network was the main constraint, followed by the storage system. The file server, as essential as it is, was almost an afterthought.

With 200Gb and 400Gb network adapters now available in mainstream servers (and with 800Gb on the way), and with fast solid state memory-based storage systems capable of saturating them, the slowest piece is suddenly the file server itself. A protocol implementation that cannot distribute work evenly across multiple CPU cores, cannot make use of hardware offloading features such as Remote Direct Memory Access (RDMA), or one that does not cluster effectively across multiple nodes will cap your throughput long before your hardware does.

This is the gap that our benchmarks reveal. They pit the file-sharing implementations against each other on the same network and storage, so the differences come from the implementations themselves.

Throughput: the gap widens as the network gets faster

The clearest single point of comparison is sequential read throughput against Samba, since most Linux deployments start there.

As the network and storage get faster, Fusion SMB scales toward the storage ceiling while Samba falls further behind. Fusion SMB uses a multithreaded, user-mode design with a mature multichannel implementation and full RDMA support, enabling SMB Direct. The use of RDMA on capable hardware allows for bypassing much of the networking stack, leaving more CPU capacity available for other tasks. As a result, adding a second 200Gb path roughly doubles throughput with Fusion SMB.

Samba by comparison uses a process-per-connection model and does not support RDMA. The results show that increasing the available bandwidth or storage performance does almost nothing for Samba’s numbers, as the architectural limitations prevent it from turning the extra bandwidth into client-visible throughput. The report explains this in depth. For a more complete side-by-side feature comparison, the Fusion SMB instead of Samba blog post will have you covered.

If your reference point is Windows Server rather than Samba, the report covers that comparison too. The largest gains in favor of Fusion there can be seen in random writes and small-block I/O. A more complete version of that comparison is in the Fusion SMB instead of Windows Server blog post.

AI training: feeding the accelerators

Keeping GPUs busy is a harder test than peak throughput. The MLPerf 3D-UNet benchmark simulates a real AI training workload and measures how many accelerator units a storage server can keep at or above the required 90 percent utilization threshold. This requires sustained high performance, as momentary dips in transfer rates can cause breaks or bubbles in the execution of the accelerators. In this benchmark, more passing units equate to more GPUs getting a steady flow of data from the server.

A single Fusion SMB server feeds roughly twice as many GPUs as the same host running other file server implementations such as NFSD, the Linux kernel NFS server, or NFS Ganesha, a user-space NFS server. Samba does not register a single passing accelerator with this workload, which makes it unfeasible for AI training at scale.

SMB 3, along with RDMA, multichannel, and scale-out, allows for the fast movement of very large amounts of data. On training workloads, that is what wins. For why the storage layer rather than GPU compute is the typical bottleneck in production AI, see the AI bottleneck blog post.

Checkpointing: where seconds become hours

Checkpoints are bursty, large, and frequent. A training run saves its state at regular intervals, so it can resume after a failure, and if storage cannot absorb those writes quickly, the checkpoint becomes the longest-running operation in the run.

During a trial with a 104.7 GB LLaMA3-8B checkpoint, Fusion SMB completed the save in 6.7 seconds. Samba took 28.1 seconds. NFSD and NFS Ganesha landed at 7.9 and 10.4 seconds respectively. Across hundreds of checkpoints in a multi-day run, the difference between 7 and 28 seconds compounds into hours of GPU time spent waiting on storage rather than training.

Fewer nodes, lower cost: the IBM Storage Scale deployment

In a real IBM Storage Scale deployment serving 150 GB/s of aggregate throughput, Fusion SMB replaced the existing Samba protocol layer with a much smaller footprint.

Fewer nodes naturally mean fewer licenses, less power, less cooling, less cabling, and in general a lower overhead to operate. Fusion’s performance characteristics still allow for aggregate throughput to go up rather than down.

What the report covers that this post does not

This is the high-level view. The full Fusion SMB benchmark report dives deeper:

• The complete test environment and methodology, including why caching and buffering were disabled to measure the server rather than the cache. 
• CPU and memory behavior at 2,500 simultaneous active SMB connections, where peak CPU utilization stayed under 62 percent. 
• Full FIO comparison across Samba, NFS Ganesha, NFSD, and Fusion SMB with sequential and random read and write patterns. 
• A capability-by-capability feature comparison covering all the key features and licensing. 
• How to start a 45-day evaluation on your own hardware. 

The numbers that matter are yours

Every figure here came from a controlled test environment. Yours will look different, because your network, your storage, and your workloads are different. That is the point of an evaluation: to find out which of these gaps show up most clearly on your stack. You may want to check out the full benchmark report if you are interested, and then talk to our team about running the appropriate tests on your hardware.