How NTFS and Btrfs Compression Skews Storage Benchmarks

File system compression in NTFS and Btrfs significantly alters storage benchmarking results by shifting the workload from the storage drive to the CPU and system memory. When transparent compression is active, benchmarking software ends up measuring the speed of data compression and decompression algorithms rather than the raw physical throughput of the SSD or hard drive. This article explains the mechanics of file system compression, how it artificially inflates or deflates benchmark scores depending on the test data, and how to configure your testing environment for accurate hardware evaluation.

The Mechanics of Transparent Compression

Both Windows’ NTFS and Linux’s Btrfs offer transparent file compression. "Transparent" means the operating system compresses data in the background before writing it to the disk and decompresses it when reading it back, without the user or the application knowing.

When a benchmarking tool sends a 10 GB test file to a drive with compression enabled, the file system intercepts that data in the system RAM. The CPU compresses the data, and only the smaller, compressed result is physically written to the storage medium. However, the benchmarking tool still calculates throughput based on the original 10 GB size, completely unaware that the drive only did a fraction of the work.

Artificial Inflation: The Compressible Data Trap

Many storage benchmarks—such as dd on Linux or default profiles in CrystalDiskMark on Windows—generate test files filled with repeating patterns or pure zeros (0x00). They do this so the CPU does not become a bottleneck while generating the test data.

File system compression algorithms excel at shrinking repetitive data. A 10 GB stream of zeros can be compressed into a few megabytes of metadata.

  • Write Skewing: The benchmarking tool sends 10 GB of zeros. Btrfs or NTFS compresses this in RAM using the CPU, writes almost nothing to the physical drive, and reports to the benchmark that the write is complete. The benchmark then displays impossible throughput speeds—often exceeding the theoretical limits of the PCIe bus or SATA interface—because it is actually measuring RAM and CPU cache speeds.
  • Read Skewing: When reading the file back, the drive reads a tiny amount of data, the CPU expands it into 10 GB of zeros in RAM, and passes it to the benchmark. Again, the reported read speed reflects CPU decompression speed, not storage read speed.

Throughput Deflation: The CPU Bottleneck

While compression usually inflates scores, it can also artificially lower them when testing high-speed NVMe SSDs (such as PCIe 4.0 and 5.0 drives).

Compression requires significant CPU processing power. If a benchmark uses moderately compressible data, the CPU must work hard to shrink it before the drive can write it. If the CPU can only compress data at 1,500 MB/s, a PCIe 4.0 SSD capable of 7,000 MB/s will sit idle waiting for the CPU. The resulting benchmark will falsely show the drive peaking at 1,500 MB/s.

NTFS vs. Btrfs Compression Behaviors

While both file systems skew results, they do so differently based on their underlying algorithms.

NTFS uses the LZNT1 algorithm. It is an older, relatively heavy algorithm designed to save space on slow mechanical hard drives. Because LZNT1 is not optimized for modern multi-core CPUs or multi-gigabit SSD speeds, enabling NTFS compression on a modern NVMe drive almost always results in severe throughput deflation during real-world or pseudo-random data benchmarks.

Btrfs allows users to choose between ZLIB, LZO, and ZSTD algorithms. LZO and ZSTD are modern, ultra-fast algorithms. When benchmarking on Btrfs with ZSTD or LZO enabled, massive throughput inflation is common during synthetic tests because the algorithms can compress zero-fill data faster than any SSD can write. Btrfs also uses heuristics to detect incompressible data; if it detects random data, it will skip compression, causing benchmark speeds to fluctuate wildly mid-test as the file system switches compression on and off.

How to Prevent Benchmark Skewing

To measure the actual hardware performance of a storage device rather than the efficiency of the file system and CPU, you must isolate the drive from compression variables.

  1. Use Incompressible Data: Configure your benchmarking software to use fully random data (high entropy). File systems cannot compress random data, forcing them to write the full payload to the disk. Note that the CPU will still waste cycles trying to compress the first few blocks before giving up, which adds slight latency.
  2. Disable File System Compression: Before running hardware benchmarks, ensure the target folder or drive has compression turned off. In Windows, uncheck "Compress this drive to save disk space" in the drive's Properties. In Linux (Btrfs), mount the drive without the compress or compress-force flags, or set the nodatacow attribute on the specific benchmarking directory.
  3. Test Unformatted Volumes: For pure hardware throughput testing, use tools like fio (Flexible I/O Tester) or Iometer to test the raw block device directly, bypassing the file system entirely.