You’ve probably heard that modern OS Windows don’t defragment solid state drives. Yet there is a
bug limitation in Windows 8+ that causes the OS to run this unnecessary for SSDs operation from time to time. Let’s take a closer look at how it happens.
Update (04-Dec-2014). Scott Hanselman posted the product group clarification in his blog. In short, Microsoft has confirmed SSD defrag when the system protection feature (aka system restore) is turned on, and this is by design. You’ll find my thoughts and take on this turn of events in the comments section of the Scott’s blog post.
Please keep in mind that I’m not the one who discovered this problem originally. Once I learned about it, I took my time to reproduce it and collect all the data, then submitted a thoroughly documented defect to Microsoft via the official channels. The purpose of this post is to raise public awareness, clearly explain the reasons behind this
bug behavior and provide an easy and correct workaround.
Table of contents
- How disk optimization works in Windows 8+
- How to check if your SSD has been defragmented
- How SSD defragmentation actually happens
- How bad defrag really is for SSDs
- How to avoid defragmentation of your SSD
- Is Microsoft aware of the problem?
- [update] Questions for the product team
You can type dfrgui on the Start screen to open the disk optimizer. It runs the defrag.exe utility to defragment HDDs on schedule, same as in Windows 7. This tool has been rebranded in Windows 8, because there’s a new feature now for SSDs.
Windows 7 sends TRIM commands to an SSD when files get deleted. Windows 8 takes it one step further by also sending TRIM commands for the entire SSD volume when the PC becomes idle. This action takes just a few seconds.
The ScheduledDefrag task is responsible for carrying on this assignment. The absence of visible triggers indicates that it operates under the umbrella of automatic maintenance.
This is another new Windows 8 feature primarily aimed at improving power efficiency and extending battery life in mobile PCs. It bundles all maintenance tasks and runs them under the high performance plan right after a plugged in PC becomes idle.
The real culprit is the ScheduledDefrag task, but the problem surfaces during automatic maintenance. Have you experienced it? Let’s see!
Filter the «Application» event log by the event 258 from defrag or run this PowerShell command:
Get-EventLog -LogName Application -Source "microsoft-windows-defrag" | sort timegenerated -desc | fl timegenerated, message
Alternatively, you can use my CheckBootSpeed utility that automatically collects all information and displays it to you.
Judging by the drive letter, you can easily see if your SSD drive gets defragmented. The SSD volume below has been correctly retrimmed first, but then defragged!
TimeGenerated : 05-Mar-13 16:06:28 Message : The storage optimiser successfully completed re-trim on (C:) TimeGenerated : 05-Mar-13 16:06:28 Message : The storage optimiser successfully completed defragmentation on (C:)
You may not see SSD defrag events on freshly installed Windows, but they’ll show up in a month or so, as I’ll explain below.
Upd 25-Dec-2018. This section was written during Windows 8 times. While it still holds for Windows 10, running defrag against SSD without /o or /l switches, that is
defrag C: /u /v, results in the HDD-style defrag, which wasn’t the case with Windows 8. In other words, reproducing SSD defrag in Windows 10 is super easy. If it were that easy back then, it wouldn’t have taken so much time and effort to get Microsoft admit it :) /end of upd.
Windows settings out of the box lay the foundation for SSD defragmentation. Then the actual defrag is just a matter of time.
The Task Scheduler service must be enabled as well as defrag and maintenance tasks. Also, the volume fragmentation level should be above 10%. You can analyze the drive state with the following command:
defrag /a C:
Upd. System Protection should be turned on per the product group. Note that while Task Scheduler condition is obvious, the fragmentation level is strictly my conclusion based on experiments (PG never mentioned this).
From the file system point of view, files can get fragmented both on HDDs and SSDs. But on solid state drives it has nothing to do with how data is actually distributed across NAND cells. The SSD controller is actually responsible for the optimal data placement, and its firmware has NAND defrag / garbage collection algorithms to achieve this.
Both the disk optimizer and the defrag.exe command line tool work correctly, if the latter receives the documented command line parameters. You can verify this by optimizing the SSD in GUI or running the following command:
defrag /o /u /v C:
The new command line parameter /o is responsible for selecting the correct optimization technique based on the drive type. Namely, HDDs get defragged, while SSDs get retrimmed. I haven’t found any issues with the /o parameter, but there’s a specific retrim parameter /l that we’ll put to use later on.
In this case, even if the defrag analysis shows the fragmentation over 10%, the OS will only send the set of TRIM commands to the solid state drive.
The actual culprit is the ScheduledDefrag task that passes a mysterious parameter $ to defrag.exe in the command. If your SSD fragmentation is over 10%, you can run the task to observe the problem.
But in practice it occurs when defrag starts from manual or scheduled automatic maintenance. Actually, you can run the former right from the Action Center in the Control Panel.
Whether you run the defrag or maintenance task, your SSD gets pounded with 5 passes of real defragmentation meant for hard drives. The last time I reproduced this I had the Russian UI, so you get to see it through my eyes :) But later in this article you’ll see the same process in the English UI, and you can also see it in German here along with disk activity during the ordeal.
The event log keeps the record of the procedure, and after its completion the defrag analysis shows 0% fragmentation.
- Exclude the SSD from automatic maintenance in the Disk Optimizer settings.
- Wait for about a month, which is usually enough for your files to become fragmented above the threshold.
- Include the SSD in automatic maintenance.
- Start maintenance manually.
I tried to speed things up by fragmenting the SSD and running the maintenance task, but it didn’t work realiably unlike natural conditions.
SSDs should not be defragged by the software meant for HDDs. Imagine that the controller has just optimally placed all data in NAND cells. The OS has no idea about it, because it only sees whether the file system is fragmented. The defrag utility starts moving file fragments around. Yet in the end the OS view still doesn’t correspond to the physical data placement on the SSD, so all this was useless!
This activity causes a lot of read-modify-write operations to the flash memory. Technically, it uses up NAND write cycles and reduces SSD lifespan.
However, in reality your SSD life depends much more on the NAND resource, controller algorithms and tasks you perform on the PC. These tasks are also fundamental to the file system fragmentation speed from the OS standpoint. Since defrag runs only when 10% of the volume gets fragmented, on a typical PC it occurs about once a month.
Here’s the data my blog readers have kindly provided. All 14 PCs run Windows 8 on SSD .
Upd. Per the product group, the scheduled task checks every week if the SSD has been defragged in the last 28 days, and if it hasn’t it defrags. If not, it checks again next week. But we’ve already figured this out empirically :)
The bottom line is that defrag won’t kill your SSD, but it’s not needed.
- Disable anything in Task Scheduler (unless instructed so), because this blocks either HDD defrag or other maintenance tasks.
- Edit the ScheduledDefrag task, because Disk Optimizer (dfrgui) won’t work until you agree to restore the default task parameters. Try it and see for yourself.
Regardless of what drives you have in your PC, there are two simple steps to get around the problem.
Note. If all your drives are SSDs, you should skip Step 1, and disable the ScheduledDefrag task after Step 2.
Open the disk optimizer (dfrgui):
- Press "Change Settings".
- Press "Choose" and remove checkboxes from SSD volumes.
The method I suggest may look strange at the first glance, but I’ll explain the reason behind it in a minute.
- Open Task Scheduler (taskschd.msc) and navigate to Library — Microsoft — Windows — Defrag.
- Right-click the ScheduledDefrag task and export it with the name TRIM-SSD on your Desktop.
- Open the XML-file in a text editor (e.g. Notepad) and change the description and arguments. In particular, the «Arguments» node must list only SSD drive letters and -l -h switches (TRIM and high priority respectively). For example:
<Arguments>C: D: -l -h</Arguments>
<?xml version="1.0" encoding="UTF-16"?> <Task version="1.4" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task"> <RegistrationInfo> <Source>Microsoft Corporation</Source> <Author>Microsoft Corporation</Author> <Description>This task trims SSD.</Description> <SecurityDescriptor>D:AI(A;;FA;;;BA)(A;;FA;;;SY)(A;;FRFX;;;LS)(A;;FR;;;AU)</SecurityDescriptor> </RegistrationInfo> <Triggers /> <Principals> <Principal id="LocalSystem"> <UserId>S-1-5-18</UserId> <RunLevel>HighestAvailable</RunLevel> </Principal> </Principals> <Settings> <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy> <DisallowStartIfOnBatteries>true</DisallowStartIfOnBatteries> <StopIfGoingOnBatteries>true</StopIfGoingOnBatteries> <AllowHardTerminate>true</AllowHardTerminate> <StartWhenAvailable>true</StartWhenAvailable> <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable> <IdleSettings> <StopOnIdleEnd>true</StopOnIdleEnd> <RestartOnIdle>false</RestartOnIdle> </IdleSettings> <AllowStartOnDemand>true</AllowStartOnDemand> <Enabled>true</Enabled> <Hidden>false</Hidden> <RunOnlyIfIdle>false</RunOnlyIfIdle> <DisallowStartOnRemoteAppSession>false</DisallowStartOnRemoteAppSession> <UseUnifiedSchedulingEngine>true</UseUnifiedSchedulingEngine> <MaintenanceSettings> <Period>P7D</Period> <Deadline>P1M</Deadline> <Exclusive>false</Exclusive> </MaintenanceSettings> <WakeToRun>false</WakeToRun> <ExecutionTimeLimit>PT72H</ExecutionTimeLimit> <Priority>7</Priority> </Settings> <Actions Context="LocalSystem"> <Exec> <Command>%windir%\system32\defrag.exe</Command> <Arguments>C: D: -l -h</Arguments> </Exec> </Actions> </Task>
- Import the modified file to the Task Scheduler.
You’re all set! The new task runs when triggered by automatic maintenance. However, it only sends TRIM commands to the SSD volumes you specified, and does not defrag SSD by mistake.
If for some reason you’ve disabled automatic maintenance (not recommended), on the "Triggers" tab, configure the task to run weekly at any time.
Why bother with export/import?
If you routinely work with an administrative account, you can create a basic task instead. However, my method works equally well for regular user accounts that don’t have permissions to run defrag. The original task runs in the LocalSystem context, and so does the modified task you’ve created with minimal effort!
A better question is whether the right product group is aware. It could’ve been, but… Here’s a case in the Answers forums, but the poster is sent away to the TechNet forums by the support engineer. Here’s a different case in the TechNet forums that basically dissects the problem, but it’s not given any attention from Microsoft.
These forums threads are not new by any means, yet the problem is still reproducible… I’ve raised a defect on Microsoft Connect, but at this time I have no indication that it’s been forwarded to the product group. I’ll keep you posted.
Upd. (Feb 2014). I’m pretty sure that my bug report never reached the product team and now I know it never will.
@mdsharpe I just talked to that team. Bad message but no actual defragging happens.
— Scott Hanselman (@shanselman) February 4, 2014
I guess «bad message» means that the defragmentation message recorded in the event log is erroneous. However, if Windows erroneously reports SSD defragmentation without actually performing it, as sort of confirmed by the team, I have a few simple questions.
- Why is the SSD defrag message recorded only when defrag is performed as a part of automatic maintenance and never recorded when optimization is done in dfrgui or via the command line with defrag /o? Note that I’m not saying that SSD gets defragged during every automatic maintenance run (read the post).
- Why does Windows log two messages at the same time when defrags SSD during automatic maintenance? Let’s assume there’s a “correct” one about TRIM and the “erroneous one” about defrag. What operation does each message actually represent?
- Why would dfrgui display 5 passes of SSD defragmentation and take its time to perform them with high disk utilization when the issue is being reproduced? TRIM neither makes these passes, nor takes that long to perform with the same tool.
- Why does defrag /a show 10+% defragmentation before defrag is run from automatic maintenance and 0% afterwards? You would have to translate Russian text, but the numbers are pretty clear (highlighted).
C:\Windows\system32> defrag /a c: d: Оптимизация диска (Майкрософт) (c) Корпорация Майкрософт, 2012. Вызов анализ на Win8-SSD (C:)... Операция успешно завершена. Post Defragmentation Report: Сведения о томе: Размер тома = 111,44 ГБ Свободное место = 42,28 ГБ Общий объем фрагментированного пространства = 11% Максимальный размер свободного места = 23,55 ГБ Примечание. В статистику фрагментации не включаются фрагменты файлов, размер которых превышает 64 МБ. Рекомендуется выполнить дефрагментацию этого тома.
PS C:\Windows\system32> defrag /a c: Оптимизация диска (Майкрософт) (c) Корпорация Майкрософт, 2012. Вызов анализ на Win8-SSD (C:)... Операция успешно завершена. Post Defragmentation Report: Сведения о томе: Размер тома = 111,44 ГБ Свободное место = 40,53 ГБ Общий объем фрагментированного пространства = 0% Максимальный размер свободного места = 33,16 ГБ Примечание. В статистику фрагментации не включаются фрагменты файлов, размер которых превышает 64 МБ. Дефрагментация этого тома не требуется.
The inconvenient truth is that you can’t just dismiss these questions by claiming a "bad message". You have to read the entire post and get familiar with the arguments and evidence. Then it may take a month or so to reproduce the defrag.
Only the product team can stop sending the bad message to the customers and clarify the issue from the technical standpoint by answering the questions above.
Please don’t refer me to some old posts on Microsoft TechNet, SuperUser and other forums that contain some basic explanations about what disk optimizer does. I’ve studied them all.
I took my time analyzing the problem, clearly identifying the culprit, collecting the logs, submitting a very detailed bug report along with all logs to MS Connect (where it died). So I strongly suggest you do the homework before claiming that information posted here is incorrect.
Please look into the problem with an open mind and stick to the facts, and not claims based on your beliefs. I’m always open to technical disscussion :)
For some reason, comments stopped showing under the article (this is a WordPress page, not a post), and I’m yet to find time to fix this…