This content was auto-generated from Fusion SMB documentation and is pending SME review. Please verify accuracy before using in partner-facing contexts.
Technical Overview
This page provides a technical foundation for understanding Tuxera Fusion SMB's architecture, protocol support, and feature set. Use this as your reference when preparing for technical conversations with prospects.
What is Fusion SMB?
Fusion SMB is a high-performance SMB stack for Linux, designed to enable seamless file sharing across Windows, macOS, and Linux environments. Built for exceptional performance and minimal latency, its multi-threaded architecture ensures efficient utilization of system resources.
Key Differentiators
| Capability | Fusion SMB | Samba |
|---|---|---|
| Architecture | Multi-threaded | Single-threaded per connection |
| Max throughput | 25 GB/s+ (production deployments saturating 400 Gbps links) | ~2.5 GB/s typical ceiling |
| SMB Direct (RDMA) | Supported | Not supported |
| Microsoft partnership | Official SMB partner and patent licensee | Community implementation |
| Footprint | Lightweight, embedded-friendly | Larger dependency footprint |
Performance Architecture Deep Dives
Three architectural decisions explain Fusion SMB's performance advantage. Pre-sales engineers should be able to whiteboard each of these.
Threads vs. Processes (Concurrency Model)
Samba uses a process-per-connection model — each client connection forks a new smbd process. Under load (e.g., 16 Win11 clients running FIO 4×4K random read/write), each process consumes significant CPU and the OS spends cycles on context switching between dozens of processes. There's no shared state, so cache locality suffers.
Fusion SMB uses a multi-threaded user-mode service — a single tsmb-server process spawns lightweight threads (transport rx/tx, VFS data/metadata) that share memory and cache. Under the same 16-client FIO load, Fusion's CPU consolidation is dramatic, and the OS schedules far fewer entities.
This is why Samba's clustering ceiling (4–16 nodes) is hit so quickly — adding nodes doesn't fix the per-node bottleneck. It's also why Fusion runs efficiently in containers: a multi-threaded service fits the container model; multi-process Samba doesn't.
TCP vs. RDMA (Data Path)
Standard SMB over TCP traverses the kernel network stack on both sides — sockets, TCP, IP, driver — for every byte. CPU is heavily involved in the data path, and latency is high.
SMB Direct (SMB over RDMA) bypasses the kernel: the application memory on the client is mapped directly to the application memory on the server via the RDMA NIC's onboard CPU. The kernel TCP/IP stack is mostly skipped. The result:
- Low latency — no kernel hops on either side
- Low CPU load — the host CPU is largely uninvolved in the data transfer
- Higher throughput per port — particularly noticeable on 100 GbE+ networks
Fusion SMB supports SMB Direct fully; Samba does not. Concrete benchmark: 11.4 GB/s (Fusion, 100 GbE RDMA) vs 2.4 GB/s (Samba, same hardware) per single client.
Direct IO vs. Buffered Writes (Data Integrity)
Samba writes pass through OS-level buffers and caches before reaching the physical storage. Data not yet written to storage is data you can lose or corrupt — power outage, kernel panic, or a network glitch during commit can leave files in an inconsistent state.
Fusion SMB supports Direct IO commits — writes go straight to physical storage without intermediate buffering. Combined with persistent file handles and transparent failover, this guarantees data integrity through power outages, network failures, and node failover events.
This matters most in regulated environments (healthcare, finance), real-time workloads (M&E, transactional), and any deployment where partial writes would cause data corruption.
Supported SMB Dialects
Fusion SMB supports all modern SMB dialects from SMB2 through SMB 3.1.1:
- SMB 2.002 / SMB 2.1 — baseline modern protocol support
- SMB 3.0 — multichannel, encryption, continuous availability
- SMB 3.02 — incremental improvements
- SMB 3.1.1 — pre-authentication integrity, compression, latest security features
SMB1 (CIFS) is not supported — this is a deliberate security decision, as SMB1 has known vulnerabilities.
Dialect configuration is flexible: administrators can expose a specific list of dialects or set a maximum dialect version to restrict older clients.
SMB over QUIC
SMB over QUIC is in active development at Tuxera. It carries SMB traffic over QUIC (the transport protocol designed to replace TCP), enabling encrypted SMB without a VPN. This aligns with Microsoft's SMB over QUIC support in Windows Server 2022+.
Why QUIC matters for SMB:
- Fewer roundtrips at connection setup — TCP+TLS 1.2 needs separate handshakes (SYN/SYN-ACK/ACK, then ClientHello/ServerHello/Cert/Key/Fin). QUIC merges them: a single Init+Hello exchange in each direction, then data flows. Lower latency on the first byte, particularly noticeable over WAN links.
- Always encrypted — TLS 1.3 is built into the protocol. Strong cipher algorithms, perfect forward secrecy, all handshake messages after Hello are encrypted.
- Better on lossy networks — UDP-based with parallel flow-controlled streams. Packets are encrypted individually (unlike TCP+TLS where stream loss blocks all downstream data). Adds reliability, congestion control, and error correction back onto UDP.
- Stops middlebox ossification — middleboxes can't peek into encrypted handshakes, so SMB stays workable as networks evolve.
On-the-wire security comparison:
| Aspect | SMB over TCP (Samba, legacy) | SMB over QUIC (Fusion) |
|---|---|---|
| Transport encryption | None (TCP is plaintext) | TLS 1.3 (always) |
| SMB payload encryption | Optional, app-level | Wrapped inside QUIC |
| Authentication exposure | NTLM challenge response visible on the wire (when not using Kerberos) | Certificate auth + TLS 1.3 — handshake is encrypted |
| Handshake roundtrips before data | ~3 (TCP) + ~2 (TLS) | 1 (QUIC init + hello) |
SMB over QUIC is shown with a working demo in Tuxera's engineering deck (May 2026). Confirm GA timeline and current release status before discussing with prospects.
Reference: SMB Dialects on docs.tuxera.com
Platform Support
Server Requirements
- Operating system: Linux (Ubuntu, Debian, RHEL, Rocky Linux, CentOS, AlmaLinux, OpenSUSE Leap)
- Architectures: x86_64, ARM64, PowerPC64
- Custom builds available for distributions not listed above
Client Compatibility
- Windows 10, 11, Windows Server 2016–2025
- macOS (via Apple Extensions support)
- Any SMB2+ compliant client
Feature Inventory
File Sharing & Protocol Features
| Feature | Description |
|---|---|
| Access Control Lists (ACLs) | Multiple ACL storage mechanisms (xattr, database), configurable per share |
| Administrative Shares | Windows-compatible administrative shares (C$, D$) |
| Apple Extensions | Native macOS client compatibility |
| Case Sensitivity | Configurable globally and per share |
| Change Notifications | Kernel-based or polling file change notifications |
| Compression | SMB 3.1.1 compression (LZ77), configurable threads and thresholds |
| DFS (Distributed File System) | Namespace support, configurable globally and per share |
| Durable Handles | V1 and V2 with configurable timeouts for resilient file handles |
| Named Streams | NTFS alternate data stream support |
| Printer Sharing | SMB printer share support |
| Recycle Bin | Server-side soft-deletion with configurable paths |
| Server-Side Copy | Offloaded copy operations, including macOS-specific support |
| Volume Shadow Copy (VSS) | Snapshot-based previous versions, configurable per share |
| Zero-Copy I/O | Reduced memory copies for read operations |
Security Features
| Feature | Description |
|---|---|
| Active Directory | Full AD integration via SSSD/Kerberos |
| Encryption in Transit | Per-share or global, with option to reject unencrypted access |
| Message Signing | Configurable requirement for SMB message signing |
| File Security Modes | Hybrid, Windows, POSIX, or None — configurable per share |
| Access Based Enumeration | Users only see shares/files they have permission to access |
| Host-Based Access Control | IP allow/deny lists per share |
| Veto Files | File pattern allow/deny lists per share |
| Audit Logging | Configurable audit trail for compliance |
| POSIX Permission Control | Creation masks and forced modes for files and directories |
Business Continuity
| Feature | Description |
|---|---|
| Active-Active Clustering | Scale-out with shared FSA state via Corosync |
| Active-Passive Clustering | Failover with floating IPs and persistent file handles |
| Continuous Availability | Persistent file handle database for seamless client reconnection |
| Connection Recovery | TCP Tickle ACK for rapid failover |
| Service Watchdog | Health monitoring with configurable intervals and timeouts |
Rolling Upgrade
Fusion SMB supports zero-downtime cluster upgrades via a rolling process:
- Stop, update, and restart one node at a time — clients automatically redistribute
- No node eviction required
- Supports n-2 version compatibility during the upgrade window
- Upon final node upgrade, all nodes automatically activate new features
- Clients receive new capabilities dynamically or on next connection
Multi-Protocol Awareness
When deployed alongside Fusion NFS, the two protocols share lock and handle state:
- Unified lock management — SMB and NFS are aware of each other's locks and handles, preventing data corruption
- Centralized ACL management — One set of admin tools manages ACLs for both protocols (compared to Samba/Ganesha where locks are not exposed between services and ACLs are separate and unmanaged)
- Safe concurrent access — Windows (SMB) and Linux/UNIX (NFS) clients can safely access the same files simultaneously
Multi-protocol awareness details are from Aaron Kennedy's IBM UG presentation (April 2026). Fusion NFS is in Private Preview — confirm what can be disclosed about multi-protocol capabilities.
Management
| Feature | Description |
|---|---|
| CLI tools | tsmb-server, tsmb-cfg, tsmb-passwd for all server operations |
| Configuration file | INI-format /etc/tsmb.conf with global and per-share sections |
| Persistent config mode | Runtime changes automatically saved to config file |
| MMC snap-in | Windows Management Console support for remote administration |
| Systemd integration | Service file for boot-time startup |
Architecture Diagram
┌─────────────────────────────────────────────────┐
│ Windows / macOS Clients │
│ (SMB 2.x / 3.x connections) │
└──────────────────────┬──────────────────────────┘
│ TCP 445 / RDMA
┌──────────────────────▼──────────────────────────┐
│ Tuxera Fusion SMB Server │
│ ┌───────────┐ ┌──────────┐ ┌──────────────┐ │
│ │ Transport │ │ SMB │ │ VFS │ │
│ │ Layer │ │ Protocol │ │ Layer │ │
│ │(rx/tx │ │ Engine │ │(data/meta │ │
│ │ threads) │ │ │ │ threads) │ │
│ └───────────┘ └──────────┘ └──────────────┘ │
│ ┌───────────┐ ┌──────────┐ ┌──────────────┐ │
│ │ Auth │ │ Config │ │ Clustering │ │
│ │(AD/LDAP/ │ │ Engine │ │ (Corosync) │ │
│ │ file DB) │ │ │ │ │ │
│ └───────────┘ └──────────┘ └──────────────┘ │
└──────────────────────┬──────────────────────────┘
│
┌──────────────────────▼──────────────────────────┐
│ Linux File System (ext4, XFS, │
│ GlusterFS, WekaFS, CephFS, GPFS, ...) │
└─────────────────────────────────────────────────┘
Fusion Service Architecture (Detailed)
Inside the Fusion SMB server, the service is structured around an OS Abstraction Layer (OAL) that wraps every interaction with the underlying kernel. All Fusion code runs in user space; the OAL is the only boundary that crosses into the OS:
Why this matters:
- User-mode safety & security — a crash in any service or protocol module brings down only that module, never the OS. Memory corruption is contained. Easier to debug, profile, and ship security fixes for than kernel code.
- OS abstraction — Fusion runs identically on every supported Linux distribution because the OAL handles distro-specific calls. Same binary semantics, no kernel module compatibility matrix.
- Service separation — authenticator, change notifications, metrics, name services run as separate user-space processes communicating via IPC with the core SMB Protocol Processor. Memory and CPU usage per service is bounded; a runaway metric collector can't impact the protocol path.
- Modular core — VFS, Transport, Crypto, Compression, and the Open DB are independent modules inside the core engine. Custom VFS modules (for GPFS and other clustered file systems) plug into this same architecture.
Compare to Samba, which spawns a new process per client connection — no shared memory, no shared cache, kernel scheduler overhead for every active session. Compare to kernel NFSD, which runs in kernel space — a bug becomes a kernel panic, and you can't deploy it in a container.
Custom VFS Layer Integration
Fusion SMB's VFS layer is pluggable — it can interface with custom VFS modules via shared libraries, enabling deep integration with specialized or proprietary file systems. This is how Fusion SMB integrates with file systems like GPFS (IBM Spectrum Scale):
- A custom shared library (e.g.,
libvfs_gpfs.so) is loaded per-share via thevfsparameter - File attributes and ACLs can be stored natively in the underlying file system rather than in extended attributes
- This avoids the overhead and lossiness of POSIX ACL mapping
[share]
netname = Data
path = /mnt/gpfs/data
vfs = /path/to/libvfs_gpfs.so
map_dos_attributes = native
map_acls = native
[/share]
This capability is relevant for OEM/NAS appliance vendors embedding Fusion SMB, and for enterprises running clustered file systems that support native Windows ACL storage.
Custom VFS integration details are from partner training sessions (Aaron Kennedy, Sep 2023, with Pixit Media). Confirm the configuration syntax and which custom VFS modules are currently available for partner distribution.
Next Steps
- Demo Environment Setup — get Fusion SMB running for a live demonstration
- PoC Guide — configure AD integration, shares, and security for a proof-of-concept
- Full documentation at docs.tuxera.com