Is there an easy way in Windows 10 to re-TRIM empty space on an SSD?

Okay, so maybe it's not the best topic title, but I'll try to explain.

Suppose you have a customized Windows 10 installation on a hard disk and you'd like to migrate it to an SSD of the exact same size (same number of sectors on both drives; Yes, I checked, they're the same!!). You use an image tool (like linux dd) to create an exact block-for-block replica of that disk (including all the empty space on the main windows partition) and burn it onto the new SSD.

Now here is where I'm getting confused. If I understand SSD's correctly, writing data to any sector/block will cause the SSD firmware to consider that block "in-use". This means the block will supposedly be left alone by the firmware wear-leveling mechanism until it is released by i.e. files using that block being deleted, and the OS issuing a TRIM/discard command to the SSD for that disk sector.

So, what happens to all the free space in this case?
I take it the SSD firmware will consider the entire disk (including all the free space) "in-use" because we've written data to the whole SSD during the cloning phase. In this case, how does one make Windows 10 signal to the SSD that all free space on the system partition should be released ("re-TRIM-med")? My current best idea is to completely fill the HDD with large files, perform the clone and then delete the files on the SSD. Any better ways?


Now, to all of you asking why I would even consider doing something like this:
I'm using system disk encryption (VeraCrypt) and I'd like to preserve all the changes I did to my Windows 10. The alternative would be to reinstall Windows (and just about everything else) on the SSD, re-encrypt and re-configure everything. Alas, something I want to avoid, if possible.

Thanks in advance for any info on this.

Gulger, this is not something that you should need to be concerned about, however, there are a few things that you can do to ensure that this issue is addressed.

First, I say that you should not need to be concerned for 2 reasons:

1) When you copied all the data to your SSD, including empty space, bear in mind that the empty space is being written to your SSD as zeros. When a TRIM operation is performed, this is effectivly what happens as well. The blocks are erased and have a value of zero.

2) Right-click on the drive letter for you SSD in File Explorer. Select Properties > Tools tab > Optimize. Make sure that scheduled optimaization is turned on. Part of this optimization is the sending of "RETRIM" operations to your SSD which informs the SSD of all the areas of the disk that should be considered empty. These hints to the SSD will trigger a TRIM operation for area areas that the SSD was not already aware that should have been TRIMed.

Finally, if you want to trigger a RETRIM manually, simply do this:

Open an elevated PowerShell prompt.

Run this command:

Code:

Optimize-Volume -DriveLetter YourDriveLetter -ReTrim -Verbose

Example:

Code:

Optimize-Volume -DriveLetter C -ReTrim -Verbose

In all liklihood, you will find that this runs and completes rather quickly.

I hope that this helps!

I neglected to mention one detail...

You could, of course, trigger the RETRIM from the GUI by selecting Optimize Now. The point of doing it from the command line was to illustrate that this is specifically a RETRIM operation that is being performed.

In fact, to illustrate that they both do the same thing, run the command as noted in my previous post, then, after it completes, go into the GUI and note that the "Last analyzed or optimized" timestamp reflects when you ran the command from PowerShell.

hsehestedt said:

1) When you copied all the data to your SSD, including empty space, bear in mind that the empty space is being written to your SSD as zeros. When a TRIM operation is performed, this is effectivly what happens as well. The blocks are erased and have a value of zero.

This is not entirely correct!
First of all, I did not write anything yet because I'm trying to understand what happens before I do anything. Second, you assume that the empty space on the hard disk was all zeros, which is not true. I have mentioned that I am using disk encryption software, and I have overwritten the HDD with random data during the encryption phase. So, even, if the empty space would technically be all zero bytes on the NTFS file system, those zeros will get encrypted by the driver and written down to the disk as seemingly random-looking data.

hsehestedt said:

2) Right-click on the drive letter for you SSD in File Explorer. Select Properties > Tools tab > Optimize. Make sure that scheduled optimaization is turned on. Part of this optimization is the sending of "RETRIM" operations to your SSD which informs the SSD of all the areas of the disk that should be considered empty. These hints to the SSD will trigger a TRIM operation for area areas that the SSD was not already aware that should have been TRIMed.

As far as I was reading the online documentation, it was said that the TRIM command will only be passed down for sectors that have recently been freed (i.e. files populating those sectors were deleted), not the entire free space range. Hence the confusion.

For example, from Wikipedia:

The TRIM command enables an operating system to notify the SSD of pages which no longer contain valid data. For a file deletion operation, the operating system will mark the file's sectors as free for new data, then send a TRIM command to the SSD. After trimming, the SSD will not preserve any contents of the block when writing new data to a page of flash memory, resulting in less write amplification (fewer writes), higher write throughput (no need for a read-erase-modify sequence), thus increasing drive life.

I will make sure the optimization is turned on after I clone the system partition.

hsehestedt said:

Example:

Code:

Optimize-Volume -DriveLetter C -ReTrim -Verbose

This is what I was looking for, thank you. Yes, the GUI options can sometimes be dubious because it isn't immediately clear what the buttons do.

Cheers!

Thanks for the clarifications. So in your situation, it is indeed the RETRIM operations that should come to the rescue. Microsoft are not a bunch of dummies - that got you six on this issue .

Gulger said:

Suppose you have a customized Windows 10 installation on a hard disk and you'd like to migrate it to an SSD of the exact same size ... You use an image tool (like linux dd) to create an exact block-for-block replica of that disk (including all the empty space on the main windows partition) and burn it onto the new SSD.

....I take it the SSD firmware will consider the entire disk (including all the free space) "in-use" because we've written data to the whole SSD during the cloning phase.....

I don't have to 'suppose', I've actually had to do that when my HDD started to die.

Why does everyone seem to think a block-for-block clone is necessary? I created a Macrium Reflect image (not a clone) and restored that to the new SSD. An image ONLY contains the in-use sectors, so that neatly avoids the issue of writing unnecessary to all the empty sectors.

But as hsehestedt has already said, even if you do write to all the sectors then "...it is ... the RETRIM operations that should come to the rescue."

Hello.

After copying the partitions and fixing the partition UUID's, I ran the retrim command posted above, and it seems to have worked: 700+ GB of empty space trimmed.

Also, TIL: Windows 10 needs same system partition and disk GPT UUID's to even boot properly.

Gulger said:

Hello.

After copying the partitions and fixing the partition UUID's, I ran the retrim command posted above, and it seems to have worked: 700+ GB of empty space trimmed.

Also, TIL: Windows 10 needs same system partition and disk GPT UUID's to even boot properly.

Or you just fix the BCD with the bcdboot command.