T wrote:
On 2020-04-27 07:30, Ken Blake wrote:
Since the folder is on an SSD, fragmentation shouldn't make any difference.


And you will reduce your wear life doing a defragment


One way to do this, is with a Macrium backup and restore,
where you use the forward and back button, go back and
"edit" the size of the destination directory. This
causes the restoration to change restore mode, and it
seems to do a file-by-file write when challenged with
even an insignificant file system size change. You don't
have to "pinch it", and in fact pinching it is not
recommended. Like, make the partition 1MB smaller,
should be enough to trigger file-by-file write mode.

This results in a "mostly defragmented" disk. Due to the
handling of the $MFT and the reserved space for $MFT,
there is some "friction fragmentation" as the reserved
space gets squeezed. I can see a little bit of
fluff that doesn't get fixed. The end result of
changing the partition size on the Macrium restore,
is a mostly defragmented partition.

To save on your SSD while doing experiments like this,
you can test on hard drives, and evaluate using nfi.exe
(mentioned in the thread already).

This approach also places an upper bound on the number
of writes and the amount of flash life you're paying
for the privilege. The Windows 10 Defragmenter is pretty
good, but some of the other defragmenters out there,
they can run all night, and that can't be good for an
SSD.

https://i.postimg.cc/Y0TCt8K5/macrium-as-defragger.gif

I noticed that "side effect" one day after a restore,
where I'd changed the destination partition size. I couldn't
believe what I was seeing. Doing that to the 1.4TB
partition in that picture was mostly a joke, as on
a data partition, you don't really need to do that.
I wanted to see whether it would change the symptoms
of another bug I'm working on (and it didn't help).

Paul