[DISCUSSION] Windows 10 Final Build 19041/2/3 (PC) [20H1/2 / 21H1 vb_release]

About the Windows 10 defrag and SSDs, things might be a bit more complex. So for context, I have 2 Samsungs, a 970 Evo+ and a 850 Evo. For both, the Optimize&Defrag will schedule a "defrag" each month (even on the default HDD "Weekly" schedule). All good.
The thing with the TRIM command is, I can execute it from something like Anvil's Storage Benchmark and basically nothing visible will happen on the SSDs. If I click Optimize though, it will trigger a write spike on the SSD (can be monitored with HWinfo64), that I've seen writing about 4-10GB on the SSD, the longer you wait between the optimizations, the more writes you have, the larger the write spike (it seems).
So while in terms of endurance and SSD life 4-10 GB written every 30-ish days is absolutely nothing, it's still interesting to notice because Windows 10 seems to execute something other than just TRIM, what that would be, I cannot tell. It does say "Trimming" for SSDs, yes.
Just a small peculiarity that everyone should be able to test.

 

Interesting, if you have your pagefile on the ssd, it could probably help to trim it more frequently. I am currently updating to the fast ring windows versions for some other reasons, i will report back if the trim bug is fixed there.

 

There are hundreds of thousands SSDs in use today with buggy firmware that have had plenty of troubles in the past with - guess what - TRIM!
And I'm talking serious data loss troubles, not just writes slow downs till it crawls..
We get 3 hotfixes for a bloody icon, but when it comes to something like this - even if it was purely cosmetic - nothing.
Just for the piece of mind of it's users Microsoft should have fixed it the very next day after it was reported.
So, caution and disregard the trolls disregarding the bug - it's them we have to thank for Microsoft's continuous lack of action where it really matters.

Optimize should NOT be used in vain! It's not "free".

 

Very true, this bug is unacceptable.

 

It is. defrag issues TRIM on LBA sectors not in use by the filesystem. This does not result in NAND erase if the LBA was accounted for as empty space (due to earlier TRIM or still empty since factory new state) because the LBA was not mapped to any NAND space to begin with (in the FTL). And TRIM only causes erase (if any), not write to NAND.
If you see a sudden write utilization spike upon executing defrag x: /Retrim that's most probably a filesystem write cache flush (similar to a sync command on Linux) which would make sense (you want the in-memory and psychical pictures in full sync before you issue this kind of TRIM). But even though flushing the write cache MIGHT increase write amplification for SOME degree, doing this once a day is a tiny drop in a huge ocean.
Even if retrim caused as much wear on your SSD as you think, it would need many years to slowly kill your SSD.

You worry about 50MB or extra write per day while my notebook switches to an uninstalled language and can't log any users in after any CU gets installed.

 

You need to login to view this posts content.

 

The File Explorer just allowed me to delete a folder from which an active move operation of a single file was still ongoing. The entire folder disappeared from the local NTFS drive, then after a while the file move operation failed. The file is not present on the mapped network driver (remote Samba share). I guess the delay between the deletion and failure happened due to local pre-caching (I moved a big file from a PCI-e SSD over the network with lots of local system RAM and slow remote storage [the file server is scrubbing the RAID volume right now]).
Is this normal behavior? I am used to getting error when I try to delete something that's open for reading.

 

19613.1000 has resolved the trim bug. just to let you guys know. i don't know what microsoft f**ked up in in the may 2020 update.

 

+1. Shoul've fixed long ago bt typical MSFT, always focus on cosmetic changes rather than imp bugfix

Well then we can expect the fix is /will be coming in 20H1 shortly, after GA probably, via CU.

 

And why no one pays attention to the fact that optimization and defragmentation occur daily with automatic maintenance of a PC that starts the execution of the ScheduledDefrag task
% windir% \ system32 \ defrag.exe -c -h -o - $ . With arguments -c -h -o - $
After the end of automatic maintenance, the date is fixed in the ScheduledDefrag task scheduler.
Each start of automatic or manual maintenance of the PC will always start the ScheduledDefrag task, regardless of whether the date is displayed in defrag UI or not.
And what does fixing dates and numbers in Defrag UI give us?

There are bugs much worse than displaying the date in defrag UI. I hope to fix both.

 

I am not one of them. I bought 4 1 TB WD HDD for the price of 1 SSD a few years ago. I can't justify buying a SSD with prices like this. Even if SSD was 10X faster. By the way, I have a 4 Bay Tower Desktop. Never owned a Laptop. .

 

Windows 10 needs a good SSD like you need water..
NVMe SSDs have been up to 2000X faster than HDDs in many areas for years, and no longer cost an arm and a leg.
But cheap ones using TLC with not so stellar lifetime to begin with, can potentially be hit hard by such windows bugs (the huge % provisioning to bump burst speeds comes to mind as something affected by mismanaged optimize). Hence the scrutiny.

 

Thanks for the Info. When my HDD's need replacing, I'll take another look at SSD's.

 

People here are mysteriously quiet about that bug and I had reported it as soon as 2nd CU was released. Even @Enthousiast is facing the same bug few pages back.
After that no one seems to care. So at the moment, I am uninstalling the previous CU and installing new CU. haha

 

You need to login to view this posts content.

 

Looks like the optimization bug is fix in 19613 but not here

 

MS will port it to 20H1 after GA, via CU.

 

There are geese that can fix this only when exiting 20H2.

 

no

 

Well, it might not be the same to all, but nevertheless it's like when you buy a car, you still would like to have the instruments to work and the paint not be scratched. What frustrates me the most when MS gets rid of a problem by categorizing it as BY DESIGN.