⚠

Auto-generated content — pending SME review

This content was auto-generated from Fusion SMB documentation and is pending SME review. Please verify accuracy before using in partner-facing contexts.

Sizing & Requirements

This page covers hardware requirements, performance benchmarks, and tuning parameters to help you size Fusion SMB deployments accurately for prospect environments.

System Requirements

Server Hardware

Component	Minimum	Recommended for Performance
CPU	x86_64, ARM64, or PowerPC64	Multi-core — Fusion SMB's multi-threaded architecture benefits directly from more cores
RAM	Depends on workload	Scale with concurrent connections and open files
Network	1 GbE	10 GbE or higher; RDMA-capable NICs for SMB Direct
Storage	Any Linux-supported device	SSD/NVMe for metadata-heavy workloads; storage throughput must match network capacity

Supported Operating Systems

Distribution	Notes
Ubuntu	LTS versions recommended
Debian	Stable releases
Red Hat Enterprise Linux	RHEL 8+
Rocky Linux	RHEL-compatible
CentOS	CentOS Stream or legacy
AlmaLinux	RHEL-compatible
OpenSUSE Leap	Stable releases

Custom builds are available for unlisted distributions.

Client Compatibility

• Windows 10, 11, Windows Server 2016, 2019, 2022, 2025
• macOS (with Apple Extensions enabled)
• Any SMB 2.x / 3.x compliant client

Performance Characteristics

Throughput Benchmarks

Fusion SMB's multi-threaded architecture delivers significantly higher throughput than single-threaded alternatives:

Metric	Fusion SMB	Samba (typical)
Peak throughput	25 GB/s+	~2.5 GB/s
Architecture	Multi-threaded	Single-threaded per connection
Network saturation	Production deployments saturating 100–400 Gbps links	Often CPU-bottlenecked

info

The 25 GB/s figure is a benchmark baseline. Production deployments with sufficient network and storage bandwidth have saturated 100 Gbps, 200 Gbps, and 400 Gbps links. Actual throughput depends on network speed, storage IOPS, workload characteristics, and tuning.

Resource Efficiency

Fusion SMB's multi-threaded architecture uses minimal system resources even under heavy load:

Test Configuration	Details
Platform	AWS c5.2xlarge (8 vCPU Intel Xeon 3.00 GHz, 16 GB RAM)
Setup	1 server VM, 8 client VMs, Debian 12
Connections	2,500 simultaneous active SMB connections
Transport	TCP (RDMA would show even lower CPU usage)
Tool	FIO from Linux CIFS mounts

CPU and memory usage remain manageable even with 2,500 simultaneously active connections — an unrealistically busy scenario that demonstrates Fusion SMB's efficiency headroom.

ML/AI Workload Benchmarks

Fusion SMB has been validated on ML training workloads:

• MLPerf 3D-unet training and llama3-8b checkpoint benchmarks show Fusion SMB outperforming NFSD, Ganesha, and Samba
• Ganesha and Samba are limited to TCP in these benchmarks (no RDMA transport support)
• FIO comparison approaches maximum storage write speed (22 GB/s on 8×RAID-0 NVMe XFS)

Test hardware: Supermicro SYS-121H-TNR, 2× Intel Xeon 2.80 GHz 6526Y, 256 GB RAM, NVIDIA ConnectX-6 200GbE RoCEv2, 8× Gen4 Samsung NVMe RAID-0 with XFS, Ubuntu 24.04.

Verify with Pre-Sales / PM

Benchmark configurations and results are from Aaron Kennedy's IBM UG presentation (April 2026). Confirm specific numbers before sharing with prospects.

Performance Testing Methodology

Use these industry-standard tools to validate performance in prospect environments:

Network baseline (iperf):

# Server
iperf -s

# Client
iperf -c <server-ip> -t 30

SMB throughput (fio):

[sequential-write]
rw=write
size=1G
direct=1
directory=/data
numjobs=5
group_reporting
name=sequential-write-direct
bs=8192k
runtime=60

[sequential-read]
rw=read
size=1G
direct=1
directory=/data
numjobs=5
group_reporting
name=sequential-read
bs=8192k
runtime=60

Key benchmark: SMB throughput should approach the iperf network baseline. If it doesn't, investigate storage bottlenecks, signing overhead, or configuration tuning.

Reference: Simple Performance Testing on docs.tuxera.com

Tuning Parameters

Fusion SMB offers extensive tuning options. The parameters below have the most direct impact on performance.

Thread Configuration

Parameter	Scope	Description	Recommendation
transport_rx_threads	Global	Network receive threads	Calculate using formula below
transport_tx_threads	Global	Network transmit threads	Calculate using formula below
vfs_data_threads	Global/Share	VFS data operation threads	Do not leave at default (1) — increase using methodology below
vfs_metadata_threads	Global/Share	VFS metadata operation threads	Increase for metadata-heavy workloads (opens/closes)

caution

The default vfs_data_threads = 1 is not suitable for production. Always increase this based on workload testing.

Transport Thread Sizing Formula

Calculate transport threads based on the total number of expected TCP connections:

transport_rx_threads = RSS_connections_per_client × adapters_per_client × total_clients
transport_tx_threads = (same formula)

• RSS connections per client: Windows default is 4 TCP connections per adapter (configurable via registry; increasing to 16 improves throughput significantly)
• Adapters per client: Typically 1 for desktops, 2+ for workstations with multichannel
• Total clients: Expected concurrent client count

Example: 500 clients, single adapter, default RSS (4):

transport_rx_threads = 4 × 1 × 500 = 2000

Verify with Pre-Sales / PM

This formula is from partner training sessions (Aaron Kennedy, Sep 2023). Confirm it still reflects current best practice and whether it should be included in official sizing guidance.

VFS Thread Tuning Methodology

VFS threads control storage I/O capacity. Unlike transport threads, there is no exact formula — use an iterative approach:

1. Benchmark your storage — use fio locally to establish maximum IOPS for your storage backend
2. Start at a baseline and increase vfs_data_threads by a factor of 2× each iteration
3. Re-benchmark after each increase until SMB throughput approaches the storage IOPS ceiling
4. Separate data vs metadata — increase vfs_data_threads for read/write-heavy workloads and vfs_metadata_threads for open/close-heavy workloads

Recognizing Thread Pressure in Logs

If your Fusion SMB logs show repeated pressure messages (e.g., thread queue backpressure warnings), this is a clear signal that you need to increase the corresponding thread pool — either transport threads (network pressure) or VFS threads (storage pressure). A few occasional messages are normal; sustained flooding requires immediate tuning.

Connection Limits

Parameter	Description	Default Behavior
connections_max	Maximum client connections	Adjust based on expected user count
sessions_max	Maximum client sessions	Adjust based on expected user count
open_files_max	Maximum open files server-wide	Increase for large deployments
sess_open_files_max	Maximum open files per session	Increase if clients report TOO_MANY_OPENED_FILES

SMB Protocol Tuning

Parameter	Description	Impact
smb2_credits_max	Credits issued to clients	Controls client request parallelism
smb2_read_max	Max SMB read message size	Increase to 8 MB for enterprise (default 1 MB)
smb2_write_max	Max SMB write message size	Increase to 8 MB for enterprise (default 1 MB)
smb2_trans_max	Max SMB transact message size	Affects metadata operations

Enterprise Recommendation

For enterprise deployments with sufficient memory, increase smb2_read_max and smb2_write_max from the default 1 MB to 8 MB. Larger message sizes mean fewer round trips on the wire, directly improving throughput for large file transfers. The trade-off is slightly higher memory usage per connection.

I/O Optimization

Parameter	Scope	Description
vfs_zerocopy_read	Share	Enable zero-copy for read operations (reduced memory copies)
vfs	Share	libc:force_sync for active-passive CA; default for performance
vfs_fallocate_min/max	Share	Pre-allocate file space for write-heavy workloads

Zero-Copy Note

Zero-copy is automatically disabled for compound, signed, or encrypted SMB messages. Its benefit varies by workload — test in context.

Oplock Configuration

Parameter	Scope	Description
oplock	Global/Share	Controls opportunistic lock behavior

Restricting to Level 2 (read-only) oplocks can improve performance for read-heavy workloads by minimizing oplock break overhead.

Reference: Performance Tuning Parameters on docs.tuxera.com

Sizing Guidelines

Small Deployment (< 50 users)

Component	Specification
Server	Single node, 4+ cores, 8 GB RAM
Network	1–10 GbE
Storage	Local SSD or NAS
Topology	Standalone or active-passive for HA

Medium Deployment (50–500 users)

Component	Specification
Server	Single node or 2-node active-passive, 8+ cores, 16 GB RAM
Network	10 GbE
Storage	SAN or distributed storage
Topology	Active-passive with CA enabled

Large Deployment (500+ users)

Component	Specification
Server	Multi-node active-active, 16+ cores per node, 32+ GB RAM
Network	10–100 GbE, RDMA recommended
Storage	Clustered file system (GlusterFS, WekaFS, CephFS, etc.)
Topology	Active-active with scale-out

Sizing Checklist

When scoping a deployment, gather these data points from the prospect:

• Expected number of concurrent users
• Average file sizes and I/O patterns (read-heavy, write-heavy, mixed)
• Network infrastructure (speed, RDMA availability)
• Storage infrastructure (type, throughput, IOPS)
• HA/DR requirements (RPO, RTO targets)
• Security requirements (encryption, signing, compliance)
• AD/LDAP environment details
• Client OS mix (Windows versions, macOS, Linux)

Known Performance Considerations

Windows 11 24H2 Signing Impact

Windows 11 24H2 and Windows Server 2025 require SMB signing by default. This is a Microsoft-side change (not Fusion SMB specific) and can reduce throughput. If the prospect reports lower performance with new Windows clients:

1. Verify signing is the cause (compare with signing disabled)
2. Explain the security vs. performance trade-off
3. Signing can be disabled via Group Policy if performance is prioritized
4. Tuxera is working to improve signing performance in future releases

Reference: KB: Windows 11 Performance on docs.tuxera.com

Case Insensitivity Overhead

Enabling case-insensitive file lookups adds overhead on case-sensitive Linux file systems. Only enable where Windows compatibility requires it.

Next Steps

• Architecture & Integration — design the clustering topology
• FAQ — address common technical questions
• Full tuning guide at docs.tuxera.com

✍Knowledge Check

1. For a large deployment (500+ users), what is the recommended minimum number of CPU cores per node?

2. Which tuning parameter should NOT be left at its default value of 1?

3. Why might a prospect see lower SMB performance with Windows 11 24H2 clients?