Heya folks, it’s Ned Pyle again. As a licensed SMB protocol service, Tuxera Fusion File Share offers compression just like Windows Server – and unlike Samba – to Windows clients. SMB compression reduces copy times of files on congested or lower bandwidth networks. Today we’ll talk about SMB compression behaviors, how to enable compression, and see a real-world demo of the performance improvements offered by Fusion SMB.

SMB compression

Microsoft implemented compression in Windows Server 2022 and Windows 11. And by Microsoft, I mean me; it was my design years ago. An admin, app, or user can request compression during SMB copies with a supported server. The file is deflated as it enters the network and deflated as it exists, which means far less bandwidth and time is needed if the file is very compressible. It adds some CPU overhead, but the tradeoff is acceptable because you might save 90% of your time and network usage. As networks and storage get bigger, files keep getting bigger and, let’s face it, more inefficient. Raw media processing files, memory dump files, virtual disks, medical image files, geospatial map files, big data JSON and XML, and others can easily fill petabytes of storage now and when you need to copy them in or out of a file server, time is money.

It adds some CPU overhead, but the tradeoff is acceptable because you might save 90% of your time and network usage.

SMB compression is defined by Microsoft in [MS-SMB2]: Compressing the Message. It supports a suite of compression types, including XPRESS (LZ77), XPRESS Huffman (LZ77+Huffman), LZNT1, PATTERN_V1*, and LZ4. Windows Server negotiates XPRESS automatically with Windows clients, as it’s the best mix of CPU usage and compression efficacy. SMB compression works even when SMB is signing or encrypting traffic, and it works with multichannel. You can’t compress over RDMA but that’s probably not important since those networks are insanely fast and wide.

Tuxera Fusion implements LZ77 compression. Samba does not support compression, nor do most of the major NAS storage vendors, such as NetApp FAS, IBM Storage Scale, Synology SA, Hitachi Vantara, Nutanix Files, QNAP TS, and Dell PowerScale. Windows Server and Tuxera Fusion effectively stand alone in this capability.

Configuring Tuxera Fusion compression

Compression is easy to configure in Fusion, you just add two lines to your tsmb.conf file and restart tsmb-server:file and restart tsmb-server:

[global]
    #compression enabled
    compression_algorithms = LZ77
    compression_threads = 10
[/global]

There are many ways to request SMB compression from your Windows client. You can do it while mapping (mounting) a drive, you can configure the client to always attempt compression, and you can even do it on demand with tools like robocopy and xcopy. If the server doesn’t support compression, nothing bad happens and the user won’t get any error. Since you can map drives or have the client request compression, you don’t need to teach users or applications how to use it – they get it for free.

Compression in action

So let’s see Fusion SMB compression in action. I have a home cable broadband network with terrible upload speeds – no fiber here in my old Seattle neighborhood. Worse, to connect to Tuxera HQ – 8000km away – I need a VPN and will cross many networks over land and under sea. This combines for truly bad throughput using any protocol!

Fusion and Samba uncompressed copies are about the same here, because I’m not hitting Samba’s internal performance bottlenecks for high-speed networks and storage; Fusion File Share doesn’t have this limit, as we’ve demonstrated. This is what my terrible network allows: around 27 minutes to copy a 4GB file halfway around the world.

But when I ask the SMB server to compress, Fusion went from taking 27 minutes to only 6 minutes. An 80% reduction in copy time. The Samba server doesn’t support compression, so its copy performance remains the same – about 27 minutes.

But when I ask the SMB server to compress, Fusion went from taking 27 minutes to only 6 minutes. An 80% reduction in copy time.

The real benefit of Tuxera SMB compression

If you’re running Tuxera Fusion SMB for massive throughput and huge scalability on RDMA networks for media processing or data science clusters, you don’t need compression. But if you’re running containers in Kubernetes, VM’s in a cloud, or a big file server on premises that ingests massive and inefficient files on a busy network, Tuxera Fusion’s compression is not only saving time, but also bandwidth for other applications. Those savings combine for better overall productivity, which means your money is being spent working, not waiting. Tuxera Fusion brings you this capability; the other Linux SMB servers do not.