Verifying TRIM functionality

[alfaunits]

The only idea I could think of is below, I'm curious if there is a more direct way to tell if TRIM is actually doing something rather than showing as "supported" only

I did the following scenario on my C300 (which supposedly have TRIM, as verified via CDI and fsutil reports TRIM is passed), on an eSATA port (should not matter, it's a pass-through, not RAID):
- copy a fairly large file to the SSD (~1GB)
- delete it
- use an unerase utility to recover the file to another drive
- compare original file with the recovered file

Turns out I got a complete match If TRIM is working, the file should not match at all (it should be either all zeroes or all ones depending on how the SSD interprets TRIMmed pages). I expected that at least a good deal of the file would not match as a second option, but I got a full recovery (one case where I don't want a full recovery of data)

One thing that comes to mind is that the SSD only marks the pages unused, but a GC actually erases the blocks some time later only and the SSD treats the pages as valid until that time - this should not be so, but that would not be the first time something isn't as it should be.
I also tried to recover a file that is quite older (a few days) - almost perfect recovery also So either TRIM does not work, or GC is ridicolously slow.

Ideas?

[zanzabar]

trim only works when the drive is idle, and i dont know the time for it to start trimming but its really random. the best way ive found is to let the computer idle then see if the HDD activity light starts going off affter like 10mins

[NaMcO]

Little bit offtopic... It's hard to find a typo in windows, but i found one when using that command:

Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\>fsutil
---- Commands Supported ----

8dot3name 8dot3name managment
behavior Control file system behavior
dirty Manage volume dirty bit

Tsk tsk

[Ao1]

Win 7 issues trim commands all the time; however there is no way of knowing if the SSD acts on them. Additionally there is no standard for how an SSD should deal with TRIM commands from the OS, so different controllers behave differently.

Currently the only way to know if TRIM is being executed by the SSD is to monitor performance degradation. Intel may be updating their tool box to provide a feature that will verify if TRIM is being executed.

As an aside, when a manual TRIM is executed from the Intel Toolbox the drive is completely filled with temporary files that then get deleted. Intel drives have no garbage collection, but they are highly resistant to dirty pages.

[alfaunits]

@zanzabar, I think you are referring to Garbage Collector, not TRIM. TRIM occurs during delete, it either acts then or does not. What it does is another question though.

[Praz]

The Trim command is only sent in Win7 for a hard delete. If you were able to recover the data with an unerase utility this requirement was not met. The data needs to be deleted with the shift key or the recycle bin emptied. After trying different things I finally settled on IOMeter for Trim testing. The results seem fairly consistent. The last part of post #11 in the thread linked below kind of explains how I tested with IOMeter with the AMD drivers.

http://www.ocztechnologyforum.com/fo...l=1#post576586

[Anvil]

hIOmon is the only known way (I know of) to determine whether TRIM is both sent and processed by the drive.

Previously I've been using HDTune for a long time to check for successful TRIMs just like Praz has been using HDTach but it wont work on all SSDs.
Intel and Indilinx based SSDs are quite easy to determine but the newcomers (C300 + SF) are not responding that well to this method.
The C300 shows peak values almost without exceptions, the SF drives are not responding at all to this method.

Link to hIOmon thread

[alfaunits]

The Trim command is only sent in Win7 for a hard delete. If you were able to recover the data with an unerase utility this requirement was not met. The data needs to be deleted with the shift key or the recycle bin emptied.

Yes, I used an actual Delete, nor Recycle Bin (which is a rename).

@Anvil, how would hIomon test if TRIM is passed or not?

Related to HDTune etc. I don't think any of those can tell if TRIM is working - only how the internal distribution algorithms work.

[overthere]

@Anvil, how would hIomon test if TRIM is passed or not?

Hello alfaunits,

I have taken the liberty to reply below to your question above:

The hIOmon software (specifically, the "hIOmon I/O Monitor" component) essentially inserts itself into the "I/O stack" of the Windows operating system, thereby enabling the hIOmon software to observe the I/O operations that are actually performed.

Please see the figure at the bottom of the following web page for an illustration of where the hIOmon software can observe I/O operations within the "I/O stack":

http://www.hyperIO.com/hIOmon/hIOmonArch.htm

Now in regards to "TRIM" commands in particular, the hIOmon software can optionally be configured to capture a variety of I/O operation performance metrics associated with control I/O operations (specifically "Device Control" I/O operations) that specify "Manage Data Set Attributes (MDSA)" requests. These MDSA requests include "TRIM" action requests.

More detailed information can be found at the following URL:

http://www.hyperIO.com/hIOmon/AddOns...GadgetHelp.htm

An example and brief description of the various MDSA/TRIM related metrics that can be captured/displayed by the hIOmon software can be seen here:

http://www.xtremesystems.org/forums/...&postcount=149

And general information about the hIOmon "SSD TRIM Display Metrics Gadget" can be found here:

http://www.hyperIO.com/hIOmon/AddOns...playGadget.htm

So in short, the hIOmon software can directly observe and report upon the actual occurrence of TRIM I/O operations (including their completion status).

[Ao1]

Attached are hIOmon stats over random 6 minute duration. I deleted a couple of files (in separate instances) from the recycle bin (a 700MB file and a file less than 1MB). I then reset hIOmon and didn’t delete anything over 6 minutes. Emptying the recycle bin generates TRIM commands, but TRIM commands are also issued by the OS, even when the drive is idling.

[Ao1]

So in short, the hIOmon software can directly observe and report upon the actual occurrence of TRIM I/O operations (including their completion status).

OK now I’m confused. I thought hIOmon could only monitor TRIM commands issued from the OS. Are you saying that hIOmon can tell if the SSD actually executed them?

[Ao1]

Anvil on the hIOmon thread it looked like you established that TRIM worked on a soft raid config?

It looks like you can get a software raid 1 configuration to work as a boot drive with versions of Win 7 Pro and above by converting the drives to dynamic disks and then mirroring them from the disk management tool.

According to a post on Intel’s SSD forum “Since the data is mirrored, the OS can read a file from both drives at the same time -- the speed of reads should be linear, just like RAID0. However, writes will not be increased at all -- they will actually get slower since it has to write the data to both drives at once.”

If that is true it would be possible to get read speeds of a raid 0 array and TRIM. Too bad about the writes. Apparently you can only boot from raid 1. You can’t create a bootable soft raid 0 array.

http://communities.intel.com/thread/11793?tstart=0

[Anvil]

Yes, TRIM works on software raid in W7.

I've got the results back home. (I'll get to them late next week)

Like overthere explained, one can monitor the time it takes for the drive to "perform" the TRIM command.
If you recall one of my earlier runs comparing VMs, the SF drive came out pretty bad* because of the time it took to TRIM the drive.
(* it could have performed very close to the C300 if it wasn't for the TRIM "bug")

[overthere]

OK now I’m confused. I thought hIOmon could only monitor TRIM commands issued from the OS. Are you saying that hIOmon can tell if the SSD actually executed them?

The hIOmon software does observe TRIM I/O operations as they occur within the I/O stack of the OS.

TRIM I/O operations that are observed at the "physical device level" within the I/O stack are generally passed further down the stack, e.g., through the HBA out to the actual device (in which case the proper, corresponding TRIM device command, in accordance with the interface protocol, e.g., ATA, is issued to the device).

Now when the respective TRIM command has completed at the device (i.e., the device has acknowledged the receipt of the TRIM command and its associated parameters such as the DSRs - and possibly also performed some additional actions, see below), the device returns "completion status" for the TRIM command. This completion status, in turn, "flows" back up through the HBA and upward through the I/O stack in the OS. So consequently, the hIOmon software subsequently observes the "completion status" associated with the respective TRIM I/O operation (i.e., essentially whether the TRIM command was at least successfully received and acknowledged).

As suggested within your prior post #4 (and as noted within the following post), what exactly the device/SSD actually does with the "trimmed" blocks/sectors that were indicated by the TRIM commands it has received (and when) is, I believe, basically "vendor-specific" at the current time.

http://www.xtremesystems.org/forums/...&postcount=156

So overall, the hIOmon software can basically observe whether the respective TRIM commands were successfully issued (i.e., whether the TRIM device commands were successfully received and acknowledged) and the corresponding time duration that it took to "perform" the individual TRIM I/O operations, but what particular actions and when these actions are undertaken by the SSD as a result of these TRIM commands can be another matter (which is currently device/vendor specific).

[zanzabar]

@zanzabar, I think you are referring to Garbage Collector, not TRIM. TRIM occurs during delete, it either acts then or does not. What it does is another question though.

trim cleans the drive on delete but it will also do a defrag style operation on idle if there are cells that are semi filled on both layers (or thats how i thought trim worked on mlc). hence the OS should clean the drive up with trim when it idles, that is not all of the functionality but if its idle then starts going with u not having anything run, it has to be trim or viral.

The Trim command is only sent in Win7 for a hard delete. If you were able to recover the data with an unerase utility this requirement was not met. The data needs to be deleted with the shift key or the recycle bin emptied. After trying different things I finally settled on IOMeter for Trim testing. The results seem fairly consistent. The last part of post #11 in the thread linked below kind of explains how I tested with IOMeter with the AMD drivers.

http://www.ocztechnologyforum.com/fo...l=1#post576586

u can recover files on windows by hex editing the HDD. if the file was not over written on NTFS u can change the name space blank that replaces the 1st character in the name (telling windows that its formerly used free space) with a legal character it will show the file, the recycle bin stores and reserves the files range and original character so it can be restored until its emptied. so if u did not overwrite the space that the file occupied (as trim should do making everything unused FF) u can recover it (not with windows) so that windows will see it.

[overthere]

... Emptying the recycle bin generates TRIM commands, but TRIM commands are also issued by the OS, even when the drive is idling.

Ao1 raises a good point. I would add that it seems like most folks understandably focus largely (if not solely) upon "emptying the recycle bin" and/or "hard deletes via shift key" when considering what causes TRIM commands to be generated in Win 7.

I suspect that there are other explicit (again, essentially manual) actions that can also directly incur TRIM commands (perhaps, for example, a "copy and replace file" action).

But I also believe that there are (or can be) other, "less visible, implicit" activities such as applications that (internally create and subsequently) delete files (including "temporary" files, moreover in a manner largely unbeknownst to users). Such deletions presumably also entail subsequent TRIM commands.

In any case, the key notion is that TRIM I/O operations can be observed (that is, by a tool that can capture the actual occurrence of such I/O operations) even during time periods when one believes that the "system/computer is currently idle".

And also along these lines I suppose my personal bias shows - that is, my preference for empirical data/metrics. Anyone interested in (re)confirming my presumptions above?

[zanzabar]

Ao1 raises a good point. I would add that it seems like most folks understandably focus largely (if not solely) upon "emptying the recycle bin" and/or "hard deletes via shift key" when considering what causes TRIM commands to be generated in Win 7.

I suspect that there are other explicit (again, essentially manual) actions that can also directly incur TRIM commands (perhaps, for example, a "copy and replace file" action).

But I also believe that there are (or can be) other, "less visible, implicit" activities such as applications that (internally create and subsequently) delete files (including "temporary" files, moreover in a manner largely unbeknownst to users). Such deletions presumably also entail subsequent TRIM commands.

In any case, the key notion is that TRIM I/O operations can be observed (that is, by a tool that can capture the actual occurrence of such I/O operations) even during time periods when one believes that the "system/computer is currently idle".

And also along these lines I suppose my personal bias shows - that is, my preference for empirical data/metrics. Anyone interested in (re)confirming my presumptions above?

your right, there is no way to see if trim is working, or atleast for normal users. the best way is if u have had a drive or FW that did not do trim then u would know how a degraded drive preforms and u can tell if a drive is degraded when u try to write and it dose not work properly

[overthere]

your right, there is no way to see if trim is working, or atleast for normal users. the best way is if u have had a drive or FW that did not do trim then u would know how a degraded drive preforms and u can tell if a drive is degraded when u try to write and it dose not work properly

I am not sure what you mean by "working" (and "work properly").

As mentioned in my prior post #9 above, you can certainly use a tool (like hIOmon) to readily see/observe the actual occurrence of TRIM I/O operations (i.e., the issuance of TRIM I/O operations by the OS and their "completion status", the various parameters associated with these TRIM I/O operations, etc.).

Moreover, these observations can be captured by normal users during their everyday usage of their own particular computer systems.

So in this sense of "working", you can verify/confirm that TRIM I/O operations are actually being "performed" (at least to the extent that they are actually being issued by the OS and successfully being received/completed by the device).

But if you mean by "working" the specific extent to which TRIM commands impact (i.e., presumably improve) the subsequent performance of a particular SSD, then that certainly is a larger endeavour.

And there can be a variety of approaches taken towards such a goal. But it seems to me from the outset that important items are required regardless of the approach taken; these items include the following:

1. The collection of I/O operation performance metrics that are directly related to the TRIM I/O operations themselves. Certainly you need to at least reasonably know the extent and nature of the TRIM I/O operations that have been issued by the OS. Simply knowing that the device, firmware, drivers, software, etc. support TRIM (and are "enabled for TRIM") is not sufficient. I submit that you also need to know the nature and extent to which the OS actually tried to "trim" - after all, it's the actual TRIM usage that is of principal interest (and not perhaps some other underlying, unrecognized factor).
   
   Put in other words, if you don't exactly know whether TRIM I/O operations were actually performed (and the extent of their usage), how can you attempt to judge their particular impact upon performance?
   
   
2. The collection of at least a basic set of I/O operation performance metrics that are agreed-upon as reflecting the improvement/degradation of performance.

And then there is the issue of flash endurance related to TRIM and performance, but that's another story.

[alfaunits]

I was only curious if TRIM works on delete at hardware level, and what it does exactly.
I know TRIM is sent, that part is not an issue of course, but we need a way to tell if it really does something.

If one can recover a deleted file, after some time, then either TRIM is not doing anything or it only marks pages unused but the GC takes ages to do anything about it. I don't like either option

[Ao1]

...I suspect that there are other explicit (again, essentially manual) actions that can also directly incur TRIM commands (perhaps, for example, a "copy and replace file" action).

But I also believe that there are (or can be) other, "less visible, implicit" activities such as applications that (internally create and subsequently) delete files (including "temporary" files, moreover in a manner largely unbeknownst to users). Such deletions presumably also entail subsequent TRIM commands.

Thanks for the explanations.

If I monitor static data only on a SSD it is easy to see what triggers a TRIM command.

• Delete to recycle bin = no
• Empty recycle bin = yes
• Temporary files = yes
• Manual TRIM command from the Intel Toolbox = yes
• Save and edit a word document = yes

It seems that a TRIM command is issued as soon as something is marked for a permanent delete.

If the SSD does not immediately act on the TRIM command it would have to store it until it could be executed, which seems unlikely.

[overthere]

I was only curious if TRIM works on delete at hardware level, and what it does exactly.
I know TRIM is sent, that part is not an issue of course, but we need a way to tell if it really does something.

If one can recover a deleted file, after some time, then either TRIM is not doing anything or it only marks pages unused but the GC takes ages to do anything about it. I don't like either option

OK, I think that I now have a better understanding of where your interest lies.

Rather than the performance implications per se of TRIM, it sounds like you are interested in determining/verifying the subsequent data content of sectors that have been trimmed.

I seem to recall looking at the ATA/ATAPI specification standard and noticing in this case that the subsequent, returned data content of trimmed sectors is basically dependent upon the current settings of the IDENTIFY DEVICE data word associated with the DATA SET MANAGEMENT command.

So depending upon the particular bit settings within this IDENTIFY DEVICE data word, the returned data content "shall/may" accordingly be either all zeroes, indeterminate, etc.

A "bus analyzer/tester" type of tool could, of course, be used to determine/verify a device's conformance to the specification standard at the "hardware level".

Apart from the issue of the data returned for trimmed sectors, it seems to me that uncovering the flash management issues related to trimmed sectors (e.g., the interaction with GC) is a much more speculative effort.

[Ao1]

Advanced warning: Conjecture sprinkled with facts

AFAIK a TRIM command gives the SSD the intelligence to know what can be deleted. Without that command the SSD does not know if data is valid or not, so it just sits there.

If TRIM is not working there must be a mechanism that decides what data can safely be overwritten. What that is I have no idea. There must also be a mechanism for GC to know what data can be cleaned. What that is I have no idea.

EDIT: According to a post by an Intel mod on GC: "The controller determines when it is idle for long enough and then does a file system compare against what is actually valid on the drive. It then cleans up the dirty pages. The actually implementation of garbage varies between controllers though. The downside to idle/background garbage collection is write amplification as it may perform unnecessary writes."

"Intel SSDs do not have idle time garbage collection (ITGC) or background garbage collection (BGC) While Intel SSDs do not idle/background garbage collection, they have are very resilent to dirty pages."

So with an Intel drive with no TRIM the data must remain on the drive until it is physically overwritten.

Intel claim that using TRIM reduces wear and encourage its use, so presumably it can more efficiently clean data than the mechanism that causes data to be overwritten if TRIM is not working.

If the point of TRIM is to reset the NAND cell so it is ready to write without first doing an erase then presumably the data is unrecoverable by any means once a TRIM command is executed by the SDD, as the gate is then flipped to release the electrons. The question therefore seems to be the possibility of recovering the data in the period between the TRIM command being issued and then actually be being executed by the SDD.

I haven’t been able to verify yet, but it does not look like the OS keeps issuing the same TRIM command until it is executed, so the SSD would have to store the TRIM command if it did not execute it immediately.

As far as I can see a TRIM command, of proportionate size to the delete, is issued whenever a delete occurs and it appears that it is executed by the SSD very soon afterwards. I suspect it occurs at the same time, but can’t be 100% sure. If I run PC Mark it generates a fresh temporary file for each part of the benchmark. When each temporary file is finished with a TRIM command is issued.

If TRIM is not working for whatever reason GC presumably does the job of TRIM over a longer period when the drive is idling. If lots of writes occur there is the possibility that GC has not had time to clean enough NAND, so a write penalty is incurred. It would therefore seem to be an advantage for TRIM commands to be dealt with by the SSD sooner rather than later so that as much clean NAND as possible is always available.

To complicate matters Intel drives (and presumably all other newer gen drives) use a controller based algorithm that distributes data over the NAND chips. SF drives are also compressing data, which must make TRIM a bit trickier to implement.

The possibility of not being able to recover data is (for me) a downside to SSD. With HDD you have a good chance of getting data back, but with SSD if the controller fails the algorithm that distributes data over the NAND chips is lost forever and if the NAND gate flips the data is also lost forever.

Whilst I feel quite confident in the reliability of an Intel drive over a HDD the consequences of failure are much higher. The data is un-retrievable by any means.

If I didn’t want data to be recoverable I would be a lot happier using SSD over HDD.

[overthere]

Advanced warning: Conjecture sprinkled with facts

AFAIK a TRIM command gives the SSD the intelligence to know what can be deleted. ...

There is quite a lot that I would like to comment upon regarding Ao1's post overall, but I'll try to be brief and touch upon just the very first sentence of his post!

Fundamentally, the TRIM command is simply a means by which a file system (for instance) can inform a device that a specific set of blocks (i.e., sectors upon the device) are considered by the file system to be "deleted data blocks" (that is, sectors upon the device that the file system considers to no longer contain valid data).

So essentially (and strictly speaking) the TRIM command is a notification mechanism and nothing more. That is (and unless there have been more recent changes to the device command protocol, e.g., the ATA/ATAPI specification standard), the TRIM command does not indicate what the device should "do" with the trimmed sectors (i.e., in regards to its flash management) nor when.

As I understand it, the device can handle its "backend" processing of the trimmed sectors as it so desires (with the exception being what it "shall/may" return in regards to the data content of trimmed sectors - please see my prior post #21).

So as a means of notification only, the TRIM command is not an explicit request to perform a specific flash management action (e.g., some "wear-leveling" task). Of course, the device could choose to immediately perform such an action as part of its processing of a TRIM command, but it is not a mandate (nor a specified option) of the TRIM command proper (at least not currently as far as I know).

Accordingly, TRIM commands are generally "executed" fairly quickly (i.e., the time duration of a TRIM I/O operation is often quite short). An apparent aberration of this "timely execution" was uncovered by Anvil when using the hIOmon software as noted in the following post:

http://www.xtremesystems.org/forums/...&postcount=148

And for some comparisons:

http://www.xtremesystems.org/forums/...&postcount=155

http://www.xtremesystems.org/forums/...&postcount=157

[alfaunits]

If the point of TRIM is to reset the NAND cell so it is ready to write without first doing an erase then presumably the data is unrecoverable by any means once a TRIM command is executed by the SDD

Not so, a TRIM only MARKS a page free, but it does not (necessarily) erase the block (most probably it is not the entire block that is free but just that page or a few pages).
The only question is when is an erase performed if the entire block is free at the time of the TRIM.

I would expect a page marked as free to have specific data (i.e. all zero or all ones), whereas the test I mentioned shows the original data is read instead, even if the file was deleted for a long time. That prolly means TRIM is not doing anything (or the blocks are erased only when needed - hmph...).

[Ao1]

Thanks again overthere, please free to wade into other conjecture in that post. It is only by talking about things that I can start to understand them better. I should empathise “start” as a lot of things still seem to be going over my head