We stopped being so algorithmically cute: when you request compression, we now just try to do it because you said so. 🙂
We first introduced SMB compression in Windows Server 2022 & Windows 11. SMB compression allows an administrator, user, or application to request compression of files as they transfer over the network. This removes the need to first deflate a file manually with an application, copy it, then inflate on the destination PC. Compressed files will consume less network bandwidth and take less time to transfer, at the cost of slightly increased CPU usage during transfers.
Based on testing and analysis, we have changed the default behavior of compression. Previously, the SMB compression decision algorithm would attempt to compress the first 524,288,000 bytes (500MiB) of a file during transfer and track that at least 104,857,600 bytes (100MiB) compressed within that 500-MB range. If fewer than 100 MiB were compressible, SMB compression stopped trying to compress the rest of the file. If at least 100 MiB compressed, SMB compression attempted to compress the rest of the file. This meant that very large files with compressible data – for instance, a multi-gigabyte virtual machine disk – were likely to compress but a relatively small file – even a very compressible one – would not compress.
Starting in Build 22449, we will no longer use this decision algorithm by default. Instead, if compression is requested, we will always attempt to compress. If you wish to modify this new behavior to return to a decision algorithm, please see this article: Understanding and controlling compression behaviors.
Please use the Feedback Hub to give feedback or report issues with SMB compression, using the Files, Folders, and Online Storage > File Sharing category.
Until next time,
Ned “smooooosh” Pyle