Let's get more eyes on this. I wandered down this path while trying to identify the source on a huge number of writes to one of my new SSDs. I suggest reading the original blog post (not mine) for more info, as well as a work-around you may wish to implement should you agree with the point in that blog and this thread.
-----
Windows 8.1 Pro (and presumably all version of 8/8.1) appears to be running defrag on SSDs when certain conditions are met, those being:
1) Windows views the SSD fragmentation as being 10% or greater and
2) Defrag is run as part of Automatic Maintenance.
or 3) Defrag has never been run before
Here is the result on a fresh Win 8.1 Pro system, fully patched via Windows Update (including 8.1 Update 1). The dfrgui.exe was launched first, and Automatic Maintenance was started from Action Center. You can see that the SSD (in this case, an 840 Evo) goes through 5 passes of defrag and is then trimmed.
You can also see this via the Windows Event Viewer, by filtering for app Defrag and event id 258 or by running the following command from Powershell.
Which gets output similar to this when defrag has been run on the SSD via Maintenance and Windows views the drive fragmentaton as greater than 10%:
or like this when it hasn't and Windows views the drive fragmentation as less than 10%:
In both cases Windows is not explictly asking for a defrag. It identifies the drive as an SSD and wants to run trim, but the scheduled task that is called by Automatic Maintenance passes a $ parameter that appears to cause the problem. Again, see the original blog post for more details.
Microsoft has stated that this log message is erroneous and that defrag isn't being run on SSDs. Scott Hanselman, who works for Microsoft and contacted the appropriate MS department about this, tweeted out "I just talked to that team. Bad message but no actual defragging happens." He also posted that "Windows doesn’t defrag SSDs. Full stop. If it reports as an SSD it doesn’t get defraged, no matter what. This is just a no-op message. There’s no bug here, sorry." I'm not trying to single him out. I don't know him, his position, nor his understanding of the issue at hand. However I believe the visual proof from the animated gif above and the difference in LBAs being written between a defrag and trim shown below dispute those statements, or at least deserve clarification.
I next performed a secure erase on the drive, reinstalled Win 8.1 Pro, and patched it via Windows Update. I used Samsung Magician to pull smart info for the drive, noting the total LBAs written (3713756846).
I then started Automatic Maintenance and observed Dfrgui.exe showing the SSD being defragged. When it was finished, I refreshed Magician and noted the LBAs written (3724914820).
I again performed a secure erase, reinstalled Win 8.1 Pro, and patched it. Using Magician, the total LBAs written were 3801909858.
Next I launched Dfrgui.exe and started the Optimize process from there, where the drive is only trimmed. Refreshing Magician, and the LBAs written show 3802312332.
In the first case, when Automatic Maintenance is run and Defrag appears to actually attempt to defrag the SSD, the difference in LBAs written before and after the process is 11,157,974. In the second case, where the SSD appears to have only been trimmed, the difference in LBAs written before and after the trim process is 402,474, which is ~27 times fewer than in the defrag case.
With #LBAs * 512 = bytes written, the erroneous defrag writes ~5.3GB to the disk and the trim writes ~0.19GB
Yes, I realize the irony in that the testing is causing more writes than the "problem" at ~40GB or so per reinstall. I'd be interested in seeing results from an in-use system rather than from a fresh install, where the SSD will appear more fragmented and presumably require more writes during the defrag. I'm using the fresh install method to force the SSD defrag to run.
-----
Windows 8.1 Pro (and presumably all version of 8/8.1) appears to be running defrag on SSDs when certain conditions are met, those being:
1) Windows views the SSD fragmentation as being 10% or greater and
2) Defrag is run as part of Automatic Maintenance.
or 3) Defrag has never been run before
Here is the result on a fresh Win 8.1 Pro system, fully patched via Windows Update (including 8.1 Update 1). The dfrgui.exe was launched first, and Automatic Maintenance was started from Action Center. You can see that the SSD (in this case, an 840 Evo) goes through 5 passes of defrag and is then trimmed.
You can also see this via the Windows Event Viewer, by filtering for app Defrag and event id 258 or by running the following command from Powershell.
Code:
Get-EventLog -LogName Application -Source "microsoft-windows-defrag" | sort timegenerated -desc | fl timegenerated, messageWhich gets output similar to this when defrag has been run on the SSD via Maintenance and Windows views the drive fragmentaton as greater than 10%:
Code:
6/10/2014 3:45:10 AM
The storage optimizer successfully completed retrim on (C:)
6/10/2014 3:45:10 AM
The storage optimizer successfully completed defragmentation on (C:)or like this when it hasn't and Windows views the drive fragmentation as less than 10%:
Code:
5/18/2014 12:01:57 AM
The storage optimizer successfully completed retrim on (C:)In both cases Windows is not explictly asking for a defrag. It identifies the drive as an SSD and wants to run trim, but the scheduled task that is called by Automatic Maintenance passes a $ parameter that appears to cause the problem. Again, see the original blog post for more details.
Microsoft has stated that this log message is erroneous and that defrag isn't being run on SSDs. Scott Hanselman, who works for Microsoft and contacted the appropriate MS department about this, tweeted out "I just talked to that team. Bad message but no actual defragging happens." He also posted that "Windows doesn’t defrag SSDs. Full stop. If it reports as an SSD it doesn’t get defraged, no matter what. This is just a no-op message. There’s no bug here, sorry." I'm not trying to single him out. I don't know him, his position, nor his understanding of the issue at hand. However I believe the visual proof from the animated gif above and the difference in LBAs being written between a defrag and trim shown below dispute those statements, or at least deserve clarification.
I next performed a secure erase on the drive, reinstalled Win 8.1 Pro, and patched it via Windows Update. I used Samsung Magician to pull smart info for the drive, noting the total LBAs written (3713756846).
I then started Automatic Maintenance and observed Dfrgui.exe showing the SSD being defragged. When it was finished, I refreshed Magician and noted the LBAs written (3724914820).
I again performed a secure erase, reinstalled Win 8.1 Pro, and patched it. Using Magician, the total LBAs written were 3801909858.
Next I launched Dfrgui.exe and started the Optimize process from there, where the drive is only trimmed. Refreshing Magician, and the LBAs written show 3802312332.
In the first case, when Automatic Maintenance is run and Defrag appears to actually attempt to defrag the SSD, the difference in LBAs written before and after the process is 11,157,974. In the second case, where the SSD appears to have only been trimmed, the difference in LBAs written before and after the trim process is 402,474, which is ~27 times fewer than in the defrag case.
With #LBAs * 512 = bytes written, the erroneous defrag writes ~5.3GB to the disk and the trim writes ~0.19GB
Yes, I realize the irony in that the testing is causing more writes than the "problem" at ~40GB or so per reinstall. I'd be interested in seeing results from an in-use system rather than from a fresh install, where the SSD will appear more fragmented and presumably require more writes during the defrag. I'm using the fresh install method to force the SSD defrag to run.
Last edited:
Facebook
Twitter