Defragmentation in 2026: What Optimize Drives Does to an SSD

Someone on the team still runs a defrag on every slow machine, and on half of them it does nothing or costs something. The split is the drive type, and Windows already knows which is which. This guide covers what defragmentation is, what Optimize Drives does on a hard disk, an SSD and a virtual disk, and the one fleet rule that keeps the whole topic from being a ticket.

What Fragmentation Is and Why It Slowed Spinning Disks

A file on disk is stored in clusters, and the file system hands them out wherever there is room. Save a file, grow it later, delete the one next to it, and the pieces end up scattered across the platter. That scatter is fragmentation, and on a hard disk drive it has a cost you can hear: the read head has to physically travel to each piece, and every move is a few milliseconds the CPU spends waiting.

Defragmentation is the cleanup. The tool reads the scattered pieces and rewrites each file as one contiguous run, so the head reads it in a single sweep. On a spinning disk that was worth doing, and Windows has run it on a schedule for you since Vista. Microsoft's defrag reference still carries the one constraint that matters: the volume needs at least 15% free space, because defrag uses that space as a sorting area, and below it the pass only partly completes.

Why an SSD Does Not Care, and Why Defragging One Costs Writes

A solid-state drive has no head and no platter. Reading cluster 9 and then cluster 90,000 takes the same time as reading two neighbours, so a fragmented file on an SSD reads as fast as a contiguous one. The whole reason for defrag is gone.

What is not gone is the cost. A defrag pass rewrites files, and flash cells wear with every write, so a defrag on an SSD spends part of the drive's write budget to rearrange data into an order the drive does not benefit from. SSD controllers also map logical addresses to physical cells on their own schedule, which means the "contiguous" layout the defrag tool just built may not be contiguous in the flash anyway.

What an SSD does want is TRIM. When Windows deletes a file, the drive is not told which cells are free until a TRIM command says so, and a drive that does not know which cells are free has to erase on the fly before it writes. Sending those hints is the SSD optimization, and it is what Windows means by "retrim".

What Optimize Drives Does on Each Kind of Drive

The Windows tool is still called "Defragment and Optimize Drives", which is the source of most of the confusion. Under the name it picks an operation per media type, and Microsoft's Optimize-Volume documentation lists the defaults.

The scheduled task runs weekly by default, but the SSD row has its own clock. Per the defrag reference, the traditional optimization on an SSD, which Microsoft describes as "moving files to make them reasonably contiguous and retrim", runs once per month, and changing the task frequency does not change that cadence. So yes, Windows does move files on an SSD about once a month, and that is the part people argue about.

The reason comes from the Windows storage team, quoted by Scott Hanselman in his December 2014 post on whether Windows defragments SSDs: the Storage Optimizer "will defrag an SSD once a month if volume snapshots are enabled", because the copy-on-write behind System Restore and shadow copies gets slow on a heavily fragmented volume, and an NTFS file can hit a hard limit on how many fragments its metadata can describe. That monthly pass is a light consolidation for the file system's sake, not the full HDD-style defrag, and it is not something to switch off.

Reading the Status Line and the Switches Behind It

Open Optimize Drives from the Start menu (or run dfrgui) and each volume shows a media type, a last run and a current status. Two things about that window mislead people. The media type column is the whole decision, so a drive listed as "Hard disk drive" that you know is flash is the first thing to fix, not the status. And the last run time only updates when an analysis runs, so on an SSD it can legitimately sit a month old while the retrim has been happening on schedule.

The r/Windows10 thread below is the media-type case in one post. A USB-attached SSD showed up as a hard disk, Optimize Drives offered to defrag it, and the fix was to run the retrim directly from the command line. The reason, from the replies, is the bridge chip: a USB enclosure that presents the drive as SCSI does not pass the identification Windows uses to spot flash.

The command line gives you the same operations with more control. From an elevated prompt:

code
defrag C: /A /U          analyze only, show progress
defrag C: /O             the right operation for the media type
defrag C: /L             retrim an SSD or thin disk, nothing else
defrag C: /X             consolidate free space before shrinking a volume
defrag /C /O /H          every volume, correct operation, normal priority

/O is the switch to remember because it does what the scheduled task does. /L is the one for a flash drive Windows misread. /X matters only when you are about to shrink a partition and need the free space in one block. A plain defrag C: with no switch runs a traditional defrag, which is the one you do not want to type on an SSD by habit. The same window and the same commands skip any drive whose file system is not NTFS, ReFS or FAT, which is one more reason the FAT32 vs NTFS choice on a data drive matters.

Defrag Inside a Virtual Machine

A Windows guest on a hypervisor has a third kind of disk, and defragging it is the case that costs real money. Broadcom's guidance on guest defrag tools is direct: VMware does not recommend running them, because on a thin-provisioned disk every block the defrag moves is a new block the hypervisor has to allocate, so the VMDK grows toward its full size while the guest thinks it is tidying up. A VM running on a snapshot is worse, since every moved block lands in the delta file.

That growth is not theoretical. A separate Broadcom knowledge base article documents thin disks inflating during snapshot removal because the guest's scheduled optimization issued unmap requests that the snapshot format turned into zero-filled data on consolidation, and the workaround before vSphere 7.0 U1 was to disable the guest's automatic optimization. The r/vmware thread below is the version a technician meets: a Server 2022 VM at high I/O, a defrag running on a thin disk, and a reply from someone whose server tried to defrag a thin disk on flash-backed storage for two weeks before they killed it.

The rule for a VM is the same as for an SSD, with one addition. Windows will run the right operation when it detects the disk as thin provisioned, which needs current VMware Tools or integration services and a modern virtual hardware version. If it detects the disk as a plain hard disk, it will defrag it, and that is the case to catch. On a Hyper-V host the dynamic and differencing VHD rows in the table above get the same analyze, consolidate and retrim treatment. The storage array underneath has its own layout logic, and a guest defrag cannot see any of it.

The Fleet Rule

Across a client's machines the rule is short. Leave the scheduled task on, because Windows picks the right operation per drive and the SSD pass is doing work the file system wants. Confirm the media type is detected correctly, because that detection is the whole decision, and it fails on USB bridges, some RAID controllers and VMs without current tools. And when a disk is slow, chase the cause, because defrag has not been the cause on a flash drive in a decade.

The detection check is one command. Get-PhysicalDisk | Select FriendlyName, MediaType, BusType lists every disk with the type Windows believes it is, and Unspecified or HDD on a drive you bought as flash is the finding. If you run OpenFrame, that is a script run across a client's devices with the output collected, so the machines Windows has misread show up as a list rather than one ticket at a time.

The slow-disk ticket then has its own order. Start with the SMART data, because a flash drive with a worn-out spare area or a spinning disk reallocating sectors is slow in a way no optimization fixes, and the steps are in our guide to checking SSD health. Then look at who is using the disk: the Windows Search indexer rebuilding after an update, a Defender scan, SysMain preloading on an old hard disk, or a page file on a nearly full drive, which our pagefile.sys guide covers. Free space matters on both media types: 15% for the defrag sorting area on a hard disk, and headroom on an SSD so the controller can shuffle blocks without erasing on the fly. A disk that is busy because the CPU is swamped belongs in the CPU usage queue instead.

Every help desk has inherited the machine where a third-party defrag tool has been running nightly on the SSD since the day it was imaged. It never hurt enough for anyone to notice, and it never helped once.

The Short Version

Defragmentation rearranges files into contiguous runs so a hard disk's head can read them in one sweep, and it does nothing for a flash drive except spend writes. Windows already runs the right operation per drive: a defrag on hard disks, a retrim on SSDs, a light monthly consolidation on SSDs for the file system's sake, and consolidation plus retrim on thin virtual disks. Leave that task on, check that each drive is detected as what it is, never defrag a thin or snapshotted VM by hand, and when a disk is slow, read the SMART data and the process list before you touch Optimize Drives.

If the slow machine is a laptop that also takes an age to boot, the next read is the debloat guide, which covers the startup load that gets blamed on the disk.