Why does .vhdx take up much more space than the actual files – NTFS

I would also add:

Turn off disk defragmentation. Change block size to 16kb so each file is written into a single block.

Rational for this:

You are wanting to write 1.7GB of data a day, in 200,000 files. Assuming that these files are writen over a 24 hour day, this means around 3 files a second. This does not seem to be a significant problem for a single SATA disk so my guess is that you have other problems as well as disk performance.

(i.e. do you have enough memory? or are you paging memory to disk as well?)

However

1. Windows NTFS file systems by default attempts to defragment file systems in the background. Disk defragmentation will kill performance whilst you are defragmenting the disk. Since performance seems to already be an issue, this will only be making matters worse for you.

2. There is a balance between using small cluster sizes and IO performance in writing large files. Files and the file allocation table will not be on the same sector on the disk, so having to allocated blocks as you are writing files will cause the disk head to have to constantly move around. Using a cluster size that is capable of storing 95% of your files in one cluster each, will improve your IO write performance.

3. As other people have pointed out, using a tiny cluster size of 2k will cause fragmentation over time. Think of it like this, during the first 18 months you will be writing files into clean empty disk, but the OS doesnt know that once closed, no more data will be added to each file, so it has been leaving some blocks available at the end each file incase that file is extended later. Long before you fill the disk, you will find that the only free space is in gaps between other files. Not only that, when its selecting a gap for your file, the os does not know if you are writing a 5 block file or a 2 block file, so it can't make a good choices on where to save your file.

At the end of the day, engineering is about handling conflicting needs, and choosing the lowest cost solution to these balancing needs. My guess is that buying a larger hard drive is probably cheaper than buying faster hard drives.

For most server machines, it should probably be hitting files in %PROGRAM_FILES% at boot and initialization, and not very often after that - it should get anything it needs to run into memory, and then page-in/out as needed without having to hit the actual original file on disk again.

An exception could be log files, if they are in the directory tree that you've compressed. And in that case it's doing a ton of writes, so I don't see compression helping IO performance in any way at all. If your application(s) involve generating or seeking through large files, that would also make a difference. But in either case, you shouldn't have those files located on your system volume; if they fill up, your system is down, so you should keep such transient or growing files on a different partition (which you may or may not want to compress.)

Another exception would be if it's hitting a ton of different binaries during normal operations, but I would imagine that's much more common on a desktop machine than most servers. An exception would be a Citrix or TS server presenting complete desktop sessions; I'm sure there could be some others scenarios too.

So, I imagine the best answer would be "it depends on your server's workload. Try it with and without, with appropriate benchmarking, and tell us what you found."

As a side note, if you have new hardware, configured properly, why should free disk space on c:\ be a concern?