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!

 

Re: A few Rb RX questions concerning SSDs!

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).

 

Re: A few Rb RX questions concerning SSDs!

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:

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?

 

Re: A few Rb RX questions concerning SSDs!

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!

 

Re: A few Rb RX questions concerning SSDs!

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.

 

Re: A few Rb RX questions concerning SSDs!

Rainwalker... you're confusing TRIM with the SSD's internal garbage collection.

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.

 

Re: A few Rb RX questions concerning SSDs!

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.

 

Re: A few Rb RX questions concerning SSDs!

Fuzzfas,

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.

 

Re: A few Rb RX questions concerning SSDs!

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.

 

Re: A few Rb RX questions concerning SSDs!

Froggie,

I'm not sure about all SSD models, but the ones that I tested (OCZ, Samsung) almost immediately zero-out the space as soon as TRIM is sent.

 

Re: A few Rb RX questions concerning SSDs!

Same here.

A nice app to test if trim is working on your disk/s is "SSD TRIM check tool".
https://github.com/CyberShadow/trimcheck
http://blog.thecybershadow.net/2012/12/09/ssd-trim-check-tool/

Panagiotis

 

Re: A few Rb RX questions concerning SSDs!

Panagiotis,

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.

Isso

 

Re: A few Rb RX questions concerning SSDs!

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.

Panagiotis

 

Re: A few Rb RX questions concerning SSDs!

Oh, sorry I missed that point. Thank you Panagiotis!

 

Re: A few Rb RX questions concerning SSDs!

No need to... I missed it too the first time I ran it.

Panagiotis

 

Re: A few Rb RX questions concerning SSDs!

Nice find Panagiotis! Then a Rollback user can run it and see if TRIM is doing its job, without guessing, right?

 

Re: A few Rb RX questions concerning SSDs!

Exactly.

Panagiotis

 

Re: A few Rb RX questions concerning SSDs!

OK...thanks guys. Learned a lot.

 

Re: A few Rb RX questions concerning SSDs!

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.

 

Re: A few Rb RX questions concerning SSDs!

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?

 

Re: A few Rb RX questions concerning SSDs!

Rainwalker,

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...)

Panagiotis

 

Re: A few Rb RX questions concerning SSDs!

Did as you suggested. Results were the same

 

Re: A few Rb RX questions concerning SSDs!

At least now you know, what is really going on on your system.
And as Fuzzfas said:

and accordingly proceed.

Panagiotis

 

Re: A few Rb RX questions concerning SSDs!

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.

 

Re: A few Rb RX questions concerning SSDs!

Thankfully this experience is the exception and not the rule. Thanks again pandlouk and Fuzzfas.