RollBack RX on SSD

[WilliamP]

If that is the case, then that is a dilemma. You would have to remove Rollback, then run trim, then reinstall Rollback

[Froggie]

Greetings all! Well, I can't possibly tell you what I've just been through as far as SSDs and Windows 7 are concerned... suffice it to say that if you think I came from a swamp, you ain't seen nuttin' yet. There are issues with Windows 7 SSD detection, various SSD TRIM implementations, mainboard SATA controllers, mainboard BiOS options, the Windows-based drivers driving those controllers... I don't think I've ever seen a maze like this in my life.

Anyway, the bottom line, for me anyway, is as follows... once I was sure that Windows 7 really knew I had an SSD connected (it only learns ONCE when a clean install is performed, never later), and that Windows was using TRIM as designed... AND that the TRIM commands were actually being transferred to the SSD itself via working Windows drivers, AND the operation was really happening inside the SSD (tricky to find out), I then fired up RBRX on that well understood SSD drive and let 'er loose. Tons of snapshots and tons of rollbacks later, the drive is running just fine... and from my testing, RBRX is actually allowing TRIM to occur on the protected drive (but probably protecting its own snapshot data from that operation by filtering specific TRIM commands accordingly).

It seems to work very well at this point in time but much more testing will need to be performed.

[Owl]

WOW!

Are you going in with a logic analyser and looking at the data links?

[nexstar]

Well done Froggie . I've been deliberating about this one for the last couple of weeks since I received a reply from HDS in response to my query. They confirmed that the Trim command did get executed on the RB protected SSD drive and that it was a workaround in RB's filter drivers. As they want to stay ahead of any competitors they didn't want to provide any more detail than that, which was fair enough.

For the purposes of Trim, it seems as though the OS driver passes on info about used/unused locations directly to the microcontroller on the SSD rather than using the filing system to flag used and unused sectors. So, presumably, the RB driver does something similar but protects the RB snapshot sectors. Pure speculation on my part.

So I'd been trying to work out how you actually prove that Trim was doing its stuff on the drive and it was starting to feel like some sort of Schrodinger's Cat scenario. Was Trim working or was it only working because we were looking to see if it was working?

I'd come across a couple of potentially useful SSD utilities which I though might help. One was SSD Tweaker and the other AS SSD Benchmark.

I haven't had a window of opportunity to try this out yet but my general idea was to test it out first on a non-RB environment by doing the following:

1) Run Trim
2) Do speed test
3) Fill up drive with data
4) Delete data
5) Do speed test
6) Goto 1 until boredom sets in

There 'should' be noticeable speed differences pre and post Trim. If these were evident then the next phase was to repeat with RB installed.

Graham

[Froggie]

Originally Posted by nexstar

For the purposes of Trim, it seems as though the OS driver passes on info about used/unused locations directly to the microcontroller on the SSD rather than using the filing system to flag used and unused sectors. So, presumably, the RB driver does something similar but protects the RB snapshot sectors. Pure speculation on my part.

I will also speculate here... TRIM is a simple function. Pre-TRIM OSes never needed to tell the storage elements whether a block of data was really in use or not, the OS kept track of that. That's why every unDELETER app created can see old data if the OS hasn't written over it again... the disk itself really doesn't care what the status is, only the OS needs to know.

That changes drastically with SSDs. They have to manage the total number of writes (especially ERASEs... a special function of the NAND memory cells used to build SSDs) to each cell/block in the storage element. It's those WRITEs (ERASEs) that determine the total useful life of the SSD itself.

As a result, Windows 7 (and TRIM supporting OSes) now sends a tiny TRIM transaction to the drive that basically says... "This logical/physical block is no longer in use." It's up to the SSD as to what it does with that information. Each SSD's firmware is slightly different so their response to the TRIM information varies... but the result is the same, the data is, eventually, physically DELETED from the SSD's memory cells. The time to DELETE this data varies significantly between SSDs due to the method they use to accomplish it.... sometimes a few seconds, sometimes a few minutes, sometimes a bit later during quiet times.

Originally Posted by nexstar

So I'd been trying to work out how you actually prove that Trim was doing its stuff on the drive and it was starting to feel like some sort of Schrodinger's Cat scenario. Was Trim working or was it only working because we were looking to see if it was working?

......

I haven't had a window of opportunity to try this out yet but my general idea was to test it out first on a non-RB environment by doing the following:

1) Run Trim
2) Do speed test
3) Fill up drive with data
4) Delete data
5) Do speed test
6) Goto 1 until boredom sets in

There 'should' be noticeable speed differences pre and post Trim. If these were evident then the next phase was to repeat with RB installed.

Speed is not a good way to determine success. Quick testing will not show much of a difference in speed due to the way SSDs run their GC (Garbage Collection) functions. Some of these GC scenarios are very aggressive and result in never letting a user see a real reduction in speed... some are a little slower but you won't notice 'cause it needs a long time and lots of writing before you will notice it. Your SSD contains anywhere from 8-15% "spare" cells and those cells are used as both replacement vehicles for "worn out" cells when necessary, as well as GC management of the device itself. Believe me, these devices are NOT simple beasts.

Based on the above, and the knowledge of how the OS uses previously used space, we have a vehicle for testing the success or failure of a TRIM operation.

GIVEN... the algorithm used by the OS for writing new data de-emphasizes the use of previously used disk blocks, preferring to use brand new unused disk space rather than old, scattered, available disk blocks. It does this primarily to reduce the fragmentation of any new data written.

GIVEN... an SSD with TRIM support (not all have it) WILL, eventually, really DELETE (Erase) any data that the OS TRIMs from the drive. This is very different from magnetic hard drives where the data is not erased.

So... based on the above, an easy way to test the success or failure of a TRIM operation is to simply write a few known very SMALL files to the activated TRIM supported drive, restart your system (to insure that the OS' WRITE CACHE is flushed to the device itself), HARD DELETE those files (DELETE then DELETE from TRASH or in the case of Windows, <Shift><Del> the files), then wait about 15-min or so and use one of the FREE unDELETERs (unDELETE-360) to see if the file is still on that storage element. "Most" SSDs will have TRIMmed those files by then (some almost immediately) and you won't be able to find or unDELETE them. If TRIM is not fully operational/implemented across that file abyss, those files will be around for a long, long time... as well as any files that were deleted before TRIM was activated.

But be aware... as I mentioned in my previous post (remember "the Swamp"), there are a tons of reasons why TRIM will not be functional although you think it might. Some of them are...

1. The OS may not have TRIM turned on due to the fact that it has not detected your SSD to be an SSD. This can be accomplished manually, if necessary. If undetected, other OS options must also be turned on to allow the SSD to be as efficient as possible

2. To get maximum speed from your SSD (parallel queuing of data requests), your computer's mainboard must have hardware that supports AHCI (Advanced Host Control Interface) functionality, and must use a BiOS that allows you to select that functionality (some BiOSes lock the hardware into RAID mode which doesn't allow for AHCI functionality even if you're not using a RAID configuration). RAID configurations of SSDs (I'm not sure why you would need this other than redundancy... speed would not be an issue) DO NOT support the AHCI functionality in their appropriate drivers.

3. Even if the above functionality exists, the OS driver that's running that interface must support TRIM... many do not (no nVidia drivers do).

4. ...and of course, your SSD itself must support TRIM.

There are many traps along the way as you unravel the above 4-steps so diligence is required. I wish it were easier, but alas, it's not. You'll have much better luck with very new systems (< 2-yrs of age) getting a fully supported piece of hardware. In my case I refused to buy new hardware (my systems are around 3-yrs old)... I purchased an add-in PCI-e controller that I knew supported ACHI and its driver did too. There are even issues with this approach and older systems... the main one being PCI-e v1 vs PCI-e v2. This is primarily a speed issue in the specs, and as a result, PCI-e v1 implementations may not be able to run the SSD at its rated speed. It'll all work, it just won't be "the best that it can be."

[Froggie]

Originally Posted by Owl

WOW!

Are you going in with a logic analyser and looking at the data links?

I wish it were that easy...

Nope, just an analytical approach after trying to understand what's really happening down in "that thar swamp."

[Froggie]

Originally Posted by Froggie

There are many traps along the way as you unravel the above 4-steps so diligence is required. I wish it were easier, but alas, it's not. You'll have much better luck with very new systems (< 2-yrs of age) getting a fully supported piece of hardware. In my case I refused to buy new hardware (my systems are around 3-yrs old)... I purchased an add-in PCI-e controller that I knew supported ACHI and its driver did too. There are even issues with this approach and older systems... the main one being PCI-e v1 vs PCI-e v2. This is primarily a speed issue in the specs, and as a result, PCI-e v1 implementations may not be able to run the SSD at its rated speed. It'll all work, it just won't be "the best that it can be."

A good example of this is the Gateway GT5678 I own (it was thrown out by a neighbor, following a local power outage, who was told by the GEEK SQUAD that the mainboard and power supply had to be replaced... $325. I put in a $10 memory module and all was well ) It uses the nVidia mainboard nForce chipset. Two problems here... the Gateway BiOS locks the SATA sub-system into RAID mode which does not allow use of an AHCI option if it's even available, AND even if it was available, none of the nVidia drivers support the TRIM operation.

This is what caused me to look for a SATA 3 add-in controller (Rocket 620, 2-ports, $19) for the above system. After successful installation of the controller, and successful driver testing of both the compatible Microsoft MSAHCI driver and the Marvel driver for the controller's chipset (can use either), I then ran my SSD (Corsair FORCE 3 Series) throughput tests and noticed they were about 1/2 of what they should be. This turned out to be that the GT5678 only had a PCI-e v1 interface... only allowing me about 230mB/s throughput, about 40% of what the drive is capable of. The add-in controller is a PCI-e v2 device so it is capable of faster speeds if the spec was higher on the system's mainboard.

I have no need to replace a bunch of hardware at this time... cost isn't justified. The 240mB/s SSD runs very fast in "real life" and the system is a pleasure to use at the moment. If other hardware becomes available, of course I'll "play" a bit... that's my nature.

[Froggie]

Originally Posted by nexstar

For the purposes of Trim, it seems as though the OS driver passes on info about used/unused locations directly to the microcontroller on the SSD rather than using the filing system to flag used and unused sectors. So, presumably, the RB driver does something similar but protects the RB snapshot sectors. Pure speculation on my part.

Graham, TRIM implementation, at least as far as Windows is concerned, in its first pass has been very basic and very simple. It still flags within its file system the "usability" of the storage block as it always has... all that it has added is the simple TRIM transaction to the storage driver sub-system whenever it goes through its normal code following a DELETE transaction within its file system. Each time it marks the status of a block (in its tables) as "available," it also TRIMs that block with the storage sub-system... which is issued immediately at the same time the block is "Freed for use"... not much rocket science here.

It all works very nicely...

[nexstar]

.......or, maybe I'll just take HDS' word for it that Trim is functioning and not bother with the testing .

Many thanks for the info, Froggie. 'Swamp' seems like a very appropriate word .

Graham

[Froggie]

Originally Posted by nexstar

...or, maybe I'll just take HDS' word for it that Trim is functioning and not bother with the testing

If it's a newer SSD, the Garbage Collection schemes in most of them have gotten pretty good so that they are able to keep both the performance and the "wear" to a minimum... not quite as good as TRIM but pretty darn close.

If you don't write a ton of data (the machine isn't a highly active server), you should be able to get about 8-years out of the device.

Originally Posted by nexstar

'Swamp' seems like a very appropriate word

<grrrrgle-grg-grrrgllll-gurglllllle-gurg!> Heeeeeeeelp!!!!!