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".
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.
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.
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
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.
StartComponentCleanup is more serious bug where previous CUs are not removed. It might cause unfixable component store corruption. Yet people here are worried about graphical defrag bug which doesn't even matter. TBH, I feel that 19041 build is not fit for release to public. MS should straight go to 20H2 build this year. 2020 year is just cursed for everyone LMAO.