Formatting a 4 TB volume sized for IIS logs with the default Format-Volume -FileSystem NTFS gives you 4 KB allocation units and an MFT whose entries for the largest files are fragmented into thousands of extents. Formatting the same volume with -AllocationUnitSize 65536 wastes up to 40 KB per small file and saves measurable write amplification on the ones that matter. Neither choice is universally correct, and Data Deduplication changes the answer again.
The three features — allocation unit size, NTFS compression, and Data Deduplication — are frequently enabled together by well-meaning administrators and then blamed for slow performance. Here is what each actually does on a Windows VPS.
Allocation Unit Size: The One-Way Decision
The cluster size determines the smallest unit NTFS can allocate and, critically, the maximum number of clusters a single file can be described by before fragmentation is unavoidable. With 4 KB units, a 10 GB file is 2.6 million clusters; with 64 KB units it is 160,000. That difference shows up as reduced fragmentation on append-heavy files, which is exactly what IIS logs and SQL Server data files are.
Size guidance that holds up in practice:
- IIS logs and W3C text logs: 64 KB. Files are written sequentially and grow continuously; large units reduce metadata churn on the MFT.
- SQL Server data files: 64 KB. SQL Server reads and writes in extents of 8 pages × 8 KB = 64 KB, so aligning clusters to the extent size avoids read-modify-write at the storage layer.
- SQL Server log files: 64 KB for the same reason; log writes are sequential 60 KB flush bursts.
- General file shares with many small files: 4 KB. A 64 KB unit on a share holding 2 million 3 KB documents wastes roughly 150 GB.
- Volumes over 16 TB: 64 KB or larger, because 4 KB units exhaust the MFT’s addressing on very large files.
The decision is made at format time: Format-Volume -DriveLetter D -FileSystem NTFS -AllocationUnitSize 65536 -NewFileSystemLabel Data. Changing it later requires a reformat and data copy. Check what a volume currently uses with fsutil fsinfo ntfsinfo D: and read the “Bytes Per Cluster” line. If the volume was created by a provider template, check this before you put data on it — templates vary, and the Windows VPS setup reference notes the defaults used by common images.
NTFS Compression: Cheap on Reads, Expensive on Writes
NTFS compression operates on 16-cluster blocks, so on a 64 KB-unit volume each compression unit is 1 MB. Data is compressed by the system process asynchronously after write, which means the write itself is not slowed much but the CPU cost lands on System and can appear as unexplained CPU usage. Reads of already-compressed data are faster on CPU-bound storage because fewer bytes cross the virtual disk.
Enable it selectively, never at the volume root:
compact /c /s:D:\Logs\IISArchive /i /f
compact /compactos:query
Get-CimInstance -ClassName Win32_Volume | Select DriveLetter,Compressed
IIS W3C logs compress well — typically 8:1 to 12:1 — and are written once and read rarely, which is the ideal profile. SQL Server data files compress badly and must not be compressed: the engine already pages at 8 KB and NTFS compression adds write amplification during checkpoint and backup operations. The measurable symptom is that a database backup to a compressed volume takes 2-3 times longer than to an uncompressed one. Event ID 55 in the System log with a corrupted file record is the other failure mode when compression is applied to a volume that is also heavily fragmented.
Data Deduplication: Only Worth It at Scale
Data Deduplication (Install-WindowsFeature -Name FS-Data-Deduplication) works on 32-128 KB chunks and stores identical chunks once, with savings realised by a background optimization job. It is designed for file shares holding many similar files — VM templates, document shares, backup archives — and delivers nothing on a volume holding a few large unique files.
The feature has hard constraints worth knowing before you enable it:
- Incompatible with NTFS compression on the same volume. The volume is silently converted, or the job fails with Event ID 6144.
- SQL Server data and log files must be excluded. Dedup works on chunk boundaries that do not align with SQL Server’s 64 KB extents, and the optimization job’s memory and I/O contend with the buffer pool.
- Requires roughly 1 GB of RAM per 1 TB of deduplicated data for the chunk store metadata.
- On Windows Server 2022, the volume must not be part of a failover cluster unless the feature is configured cluster-wide.
Enable it with Enable-DedupVolume -Volume D: -UsageType HyperV for VHD stores, -UsageType Default for general file shares, or -UsageType Backup for archives. The Backup profile uses larger chunk sizes and optimises for throughput rather than savings, and it is the right profile for IIS log archives instead of Default.
Deduplication and Compression on the Same Volume
The incompatibility is not a soft warning. Enabling dedup on a volume holding compressed files excludes those files from optimization, and compact /c on a deduplicated file fails with access denied because the chunk store owns the allocation. If you need both behaviours, split by directory into separate volumes rather than layering them.
When Not to Dedupe
Three cases where dedup costs more than it saves. First, volumes under about 1 TB: chunk store overhead and job CPU exceed any savings, and Microsoft’s guidance sets 1 TB as the practical floor for the general profile. Second, write-heavy workloads: the optimization job competes with production writes, which on a VPS with a fixed IOPS budget shows up as hourly latency spikes. Third, data already compressed by the application — zip archives, JPEG images, compressed database backups — because chunking cannot find duplicate blocks in high-entropy data.
Measure before deciding. Get-DedupStatus -Volume D: reports SavingsRate and OptimizedFilesCount after the first job runs; a savings rate below 10% means you are paying the memory and CPU cost for nothing. Also check Get-DedupVolume -Volume D: | Select UsageType,MinimumFileAgeDays — the default minimum file age of 3 days is designed for shares, not for hot log volumes.
Putting the Three Together on One VPS
The layout that avoids conflict: a system volume at 4 KB units with no compression, a 64 KB-unit data volume for SQL Server with compression and dedup both off, a 64 KB-unit volume for IIS live logs with compact /c applied only to archive folders older than 7 days, and — if you need dedup at all — a separate Backup-profile volume for archives. That keeps each feature’s cost isolated and makes a performance regression attributable.
Before you format, confirm the plan gives you enough disk to keep these volumes separate; the Windows VPS disk and storage tiers list volume sizes per plan, and adding a second data disk later is far easier than reformatting one. Whatever layout you choose, record the allocation unit size in your handover notes — the next administrator who inherits a 64 KB-unit volume holding 2 million small files will otherwise spend a week wondering where the disk went.
