> All you can do is let it know that some range of sectors is not used, which is what TRIM enables, and that does not require defragmentation upfront.
This is exactly what defrag.exe does on an SSD today. Since Windows 10 (or 8?), instead of doing a "real" defrag, defrag.exe also has an option to issue TRIM commands to unused blocks on an SSD. In other words, it works like fstrim(1). The time has changed and you must have missed the update. I suggest keeping your knowledge up-to-date before delivering a lecture on disk defragmentation on a forum where everyone should've known better.
> /d Perform traditional defrag (this is the default).
> /l Perform retrim on the specified volumes.
> /o Perform the proper optimization for each media type.
Since I migrated the hard disk using a block-level copy via "dd", it's a good idea to manually TRIM the disk afterwards to inform the controller about the unused blocks in the new filesystem for proper wear leveling (to the controller, the block-level copy looks like a single large file).
And before another one gives me another lecture: No, I did not corrupt the filesystem because I made the mistake of copying the disk while Windows was still in Fast Startup mode. It was probably ntfsresize(8), to be fair, the corruption was extremely minor.
Thanks for the excellent explanation, but the attitude and needless personalization was unnecessary. This functionality was previously available via the Optimize-Volume cmdlet, I guess it makes sense the defragmenter was updated with similar functionality to account for the typical Windows user.
This is exactly what defrag.exe does on an SSD today. Since Windows 10 (or 8?), instead of doing a "real" defrag, defrag.exe also has an option to issue TRIM commands to unused blocks on an SSD. In other words, it works like fstrim(1). The time has changed and you must have missed the update. I suggest keeping your knowledge up-to-date before delivering a lecture on disk defragmentation on a forum where everyone should've known better.
https://docs.microsoft.com/en-us/windows-server/administrati...
> /d Perform traditional defrag (this is the default).
> /l Perform retrim on the specified volumes.
> /o Perform the proper optimization for each media type.
Since I migrated the hard disk using a block-level copy via "dd", it's a good idea to manually TRIM the disk afterwards to inform the controller about the unused blocks in the new filesystem for proper wear leveling (to the controller, the block-level copy looks like a single large file).
And before another one gives me another lecture: No, I did not corrupt the filesystem because I made the mistake of copying the disk while Windows was still in Fast Startup mode. It was probably ntfsresize(8), to be fair, the corruption was extremely minor.