Kurtis from Horizon DataSys offers the following as an explanation for Rollback RX's use of the SSD TRIM function (from Post #180), in response to my reluctance to even believe this function is really being performed by Rollback Rx... While I appreciate Kurtis' response in the above message, I cannot fault him for not knowing the innards of Rollback RX as well as its designers/developers do. But I surely can fault the Horizon DataSys Marketing/Develper "Party Line" (the one referenced by Kurtis above) that's offered to anyone who questions whether Rollback RX really supports TRIM... through investigation, I find the above claim to be patently FALSE. This question has nagged the Rollback user Community ever since the introduction of Windows 7 and its SSD TRIM support and the follow-on Windows 8.x... and also myself who has always found remnants of unTRIMmed SSDs while doing various testing for both HDS and other efforts. I decided to try and get to the bottom of this once and for all as I feel an unTRIMmed SSD will degrade at a greater rate over time than one that's properly TRIMmed... and that is not a good thing for the SSD lifespan. Possibly HDS uses a different definition for the SSD TRIM function than the technical community does, making its explanation above even slightly plausible, but I doubt it. Their developers and marketing people are clearly cognizant of what TRIM really means and that's what really bothers me about the offered explanation for how Rollback RX handles the TRIM requirement of SSD storage devices. Anyway, to get back to my testing (and it's actually pretty simple)... create a baseline, fill up the disk with known data patterns, take some snapshots, defrag all snapshots, delete all snapshots then uninstall Rollback RX... 1. At first I wiped the test partition with all ZEROs (the same pattern that this SSD will TRIM to). 2. I then created a basic W8.1 system followed by the installation of Rollback RX v10.3. The Rollback protected OS was appx. 16gB and the protected partition size was 55gB at Rollback's baseline. 3. From both inside and outside of the LIVE Rollback protected OS I examined the unALLOCATED disk surface and found all ZEROs as expected from Step #1. 4. I then ran a simple file generator, creating a known data pattern (different than all ZEROs) in 128mB file increments which I used to fill appx. 88% of my protected volume (about 250 files). 5. I repeated Step #3 and found my CheckData pattern in the previously unALLOCATED disk space, again as expected from Step #4. 6. I then took a single snapshot to LOCK in and reference all the files created above in Step #4. 7. Repeated Step #3 and found the CheckData pattern as expected. 8. I then created a single snapshot buffer between Step #6 and the coming deletion of all that data. 9. I then DELETED all files created in Step #4 followed by a snapshot to LOCK in the file deletion. 10. Repeated Step #3 and found the CheckData pattern... so the TRIM didn't occur here. 11. Created another buffer snapshot after the file deletion lock-in (just for the heck of it). 12. Restarted system, defragged all existing snapshots from the RBrx sub-Console, then BOOTed on into the OS. 13. Repeated Step #3 and found the CheckData pattern... hmmmmmm, TRIM didn't occur during the Rollback defrag process. 14. Under the Rollback UI, deleted ALL SNAPSHOTs except the Baseline and the CURRENT SYSTEM STATUS and reBOOTed into the OS. 15. Repeated Step #3 and found the CheckData pattern which was NOT EXPECTED. At this point I would have expected Rollback to have TRIMmed all the non-referenced data from the previous file test... it did not. 16. I then unINSTALLed Rollback to its original baseline and repeated Step #3 under both a LIVE W8.1 OS and from outside of the LIVE OS (via WinPE) and found all my CheckData pattern still resident on the SSD. Under the Rollback unINSTALLed OS, a TRIM optimization was peformed and all unALLOCATED data on the SSD reverted to its TRIM value of ZERO... TRIM was functional in the OS at the time of the test. Not one single TRIM operation had been performed on any of the data files created during my LIVE Rollback test above... all the data was still IN the SSD. As a result, the SSD must carry around all my CheckData (appx. 31gB) while executing its Garbage Collection cleanup functions... a massive burden. At this point the SSD believes its managing 49gB of data while the OS thinks it's only using 17.6 gB... a very large and burdensome discrepency. For a Rollback user, this condition can exacerbate over time as the system fills up its disk with data and "thinks" its reducing that burden by file deletions... but for the SSD the burden remains at the highest disk usage level. After a while the SSD will have exhausted its overprovisioning level (while trying to manage this non-existant data) and eventually will probably slow down quite a bit. Probably the thing that upsets me the most is that throughout all the TRIM discussion levels over the past few years, HDS has always told its users not to worry about TRIM because Rollback handles it just fine. The plain fact of the matter is that Rollback DOES NOT handle this just fine, and the claim that it does it patently false, as stated above. Feel free to ask any questions that this report may engender... I will try and expand accordingly. The BOTTOM LINE is that Rollback RX DOES NOT IN ANY WAY properly TRIM a Solid State Disk, if it even TRIMs it all all. I will be posting this information in the HDS Forum and asking them for a possible explanation for my findings.