A few Rollback RX questions concerning SSDs!

Although I post (infrequently since I've never owned a HDS product) I prefer this friendly community. I was one of the fortunate CTM users both on an XP desktop and a Vista laptop, so I have a complete understanding of how to use RB and love(d) and miss the convenience of such an app, so I'm probably going to purchase RB during the next $25 sale. I had one major BSOD on the laptop because I inadvertently un-installed CTM with a third party un-installer as opposed to its own. I restored the MBR from a Paragon image and all was good. Now I'm using a desktop I built with a SSD. I rarely kept more than two snapshots plus the baseline as I only ever restored to the last one anyway. After deleting snapshots I used CTM's defragger. A few times a month I would remove CTM, defrag, image then reinstall. Since I can't defrag my SSD, I'm thinking I could periodically remove RB and use the PC for a day allowing TRIM to do its job. Which brings me to my questions. Can I use RB's defrager? Is TRIM at work "inside" RX anyway, meaning no reason to ever do anything (i.e. use RB's defrager) but periodic un-installs and conventional imaging? Thank you!

Ratchet, at this point I'm not sure anyone can really answer the question concerning RB and TRIM. HDS claims they "support" it when using an SSD, but others have found an RB configured SSD to be marked as a RAID volume, which is not TRIMmed by Windows 7 (a very sleazy way to get around "TRIM support" if that claim is verified).

There has been speculation about how RB could/does support TRIM but the community doesn't have any definitive information from HDS.

If it makes you feel any better, today's SSDs contain excellent GC (garbage collection) and, on their own, "TRIM" the drive very well (not in the sense of freeing up unTRIMmed data but in the sense of re-organizing such to better manage <and add LIFE to> existing NAND cells used in the SSD).

Given the lack of clarity on the part of devs and the recent "revelations" in this forum, my money is on the scenario that they simply found an indirect way to disable TRIM.

I think garbage collection isn't as good as TRIM, if you write a lot on your PC. TRIM is activated everytime there is a delete. Garbage collection in order to activate you have to leave the computer on logon or logoff screen or, according to others, leave it in the BIOS.

Useful post:

While talking to Crucial about there garbage collection software for their SSD's, they told me to just either sign-off or log off your computer. Your computer will go in a rest state and the hard drives will shut down. The software will not work if there is any hard drive activity. This is when garbage collection starts working. They said to do it for at least 30 minutes, once a week. But the more the better depending on how much your writing to your drives on a daily basis.

To me it is rather obvious that without TRIM the drive is handicaped. If garbage collection was able to substitute TRIM, they wouldn't have implemented TRIM in the first place. How many people do you know that leave their PC in the logon screen for at least 30 minutes a week, let alone a day?

Thank you for the replies! Upon further review, this tutorial, which I'd never bothered to scroll all the way through, suggests that if it is harmful for SSDs there really isn't anything you can do about it, as it is defraging on its own all of the time! I'm now definitely leaning toward not purchasing it. For one thing, I also have a 60gb SSD in the PC case (no RAID configuration) I use to hold images made with Paragon. An image takes around four minutes and restore five to six. Secondly, I use W7's backup and image to an external drive for extra security. Last but not least, x64 RegSeeker has been working flawlessly hunting down leftover registry entries. Most leftover files I find myself. None of which is as convenient as a snapshot but if it keeps my equipment healthy longer, so be it!

TRIM is under control of the OS (Windows), GC is under control of the drive itself, no OS interaction. It's the GC that occurs INTERNALLY to the drive when the system is idle. TRIM is another issue all together.

This RB trim stuff is ....well, it just is. I am wondering if I allow my computer to rest for an hour or two and RB is installed, will trim kick in or has RB basically turned it off.

Click to expand...

To try to describe it simply.

TRIM is an OS command that "flags" logical blocks of the SSD as "available". It gets triggered automatically everytime you delete something on the SSD. Anything, from program to internet temporary files. This way the SSD "knows" where it can write and with its built-in controller, it attempts to use the available free space in a way that there is even wear on all modules. Cause since SSD modules have a limited write cycle life, you want to use all modules as evenly as possible, avoiding premature death (which will happen, if you keep writing always at the same place).

The garbage collection, is a similar function, which is, though, OS-independent. BUT, it's not triggered automatically all the time like TRIM. It gets triggered on special events (leaving the PC idle in log on/log off, leaving the PC in the UEFI page).

The obvious problem with garbage collection, is frequency. TRIM works "immediately" as soon as you delete something. Garbage collection works only when the "triggering event" occurs (logoff,logon) and if you let it appropriate time to do the job. Unfortunately, BETWEEN 2 different "triggering events", the SSD does NOT know what is available and thus where to write with optimum resullts. So, for example, if you make garbage collection work once a week, during the week, everything you delete and write is done "blindly", the SSD has no means to know what's the optimal strategy for the wellbeing of your SSD.

The obvious problem of Rollback with TRIM, is: Windows can't see Rollback or its snapshots. Rollback intercepts all write/delete commands from Windows to some place else, because Rollback knows where its own snapshots are. So, when you delete something, the OS sends a TRIM command to flag the cell as available. Alas! The cell may NOT be REALLY available, because Rollback may have written part of its snapshot there and Windows can't possibly know that. So, either Rollback has found a really ingenious (but not revealed pubblically) way to make Window's TRIM commands divert to the right place or, as was proposed in a topic in this forum, they 've simply fooled Windows into thinking there is a RAID array, which practically equals to disabling TRIM.

My money is on the second theory. It's easier to do and if they had an ingenious way, i think they 'd be more vocal. All the times i googled about it and ended in horizon forum, there was never a post to explain exactly how they did it and those who ask, are left with generic and vague answers from other posters that are like "yes, Rollback supports TRIM" or "works with TRIM". While when someone asks about defragging for example, they get all the details. The lack of details in this case, is worrysome.

Great detailed explanation! But let me add one more significant detail: GC and TRIM (although having similar function) are two completely different mechanisms, i.e. you can't replace TRIM by keeping the system idle waiting for GC to complete its work.

The reason is that GC never knows about deleted files. If you do the following: write files to your SSD until it's full, then delete all that files so SSD is empty, still GC will think that SSD is full. That means every time it will be shuffling all that deleted data back and forth trying to optimize the writes. The result will be slower SSD operation and decreased life.

That's why TRIM should be used in conjunction with GC, and not even smartest GC can replace TRIM.

Inside the SSD, I believe there's a hybrid of what Fuzzfas describes as TRIM and GC, I don't believe the SSD will process the TRIMmed blocks until its GC cycle, i.e., not immediately... if it did, it would cause many unnecessary writes to the NAND cells.

What it probably does is update its own NAND Cell allocation table to reflect the status of the TRIMmed block, then during GC perform both operations with the knowledge of that TRIMmed block.

Thanks for the link - looks to be a helpful utility. And I looked through its sources - it deletes a file and then checks if the content of that file on disk has changed (i.e. zeroed-out).
So it even assumes that the data is zeroed-out immediately after the file is deleted! I.e. it assumes that TRIM is sent immediately after the file is deleted, and data is zeroed right after TRIM is received. Not sure if it's always the case though.

The first time it runs, creates and deletes a file and creates another file "trimcheck-cont.json" with the offset and the hex information of the deleted file.
On the second run it reads the "trimcheck-cont.json" and checks the surface of the block where the deleted file resided.

It's up to the user how long to leave the drive to rest between the first and second run.

I ran fsutil behavior query DisableDeleteNotify and it showed trim to be working. Then ran SSD TRIM check tool and it showed it not to be working. I am wondering if this is the result of RB fooling Windows into thinking there is a RAID array. Something is rotten in Denmark.

I ran fsutil behavior query DisableDeleteNotify and it showed trim to be working. Then ran SSD TRIM check tool and it showed it not to be working. I am wondering if this is the result of RB fooling Windows into thinking there is a RAID array. Something is rotten in Denmark.

Click to expand...

Then your TRIM is not working and the suspicions about Rollback are founded. The fsutil command simply shows whether Windows is sending commands or not. The problem is: Windows is sending the TRIM commands, but Rollback makes them disappear. If Rollback makes it appear as RAID, as was suggested, it's no wonder. TRIM doesn't support RAID arrays.

And so much about the "Rollback supports TRIM"...

Well, at least, now thanks to Panagiotis, we know beyond doubt how Rollback dealed with "TRIM". And the question comes: Do you value more your need for Rollback or your SSD's life?

for a complete test you should do the following.
1) run "SSD TRIM check tool" (first time)
2) run "SSD TRIM check tool" (second time). (if it fails confirms the raid array suspicions.)
3) take a snapshot.
4) run a defrag with RollbackRX and then run " SSD TRIM check tool" again (third time). (if it fails means that the live defrag does not send trim commands to the ssd)
5) run a boot time defrag with RollBackRX and after entering in windows run "SSD TRIM check tool" a last time. (if it fails even after that... nothing more to say...)

for a complete test you should do the following.
1) run "SSD TRIM check tool" (first time)
2) run "SSD TRIM check tool" (second time). (if it fails confirms the raid array suspicions.)
3) take a snapshot.
4) run a defrag with RollbackRX and then run " SSD TRIM check tool" again (third time). (if it fails means that the live defrag does not send trim commands to the ssd)
5) run a boot time defrag with RollBackRX and after entering in windows run "SSD TRIM check tool" a last time. (if it fails even after that... nothing more to say...)

Having TRIM slyly disabled + no disk imaging support are two big no no's for me recommending this to clients. Perhaps in the future. But not now. Till then I prefer to stick with tried and true disk imaging for disaster recovery.