Verifying TRIM functionality

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?

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

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

Quote:

---

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

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.

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

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

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

Quote:

---

Originally Posted by 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.

---

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.

Quote:

---

Originally Posted by alfaunits

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

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.

Quote:

---

Originally Posted by overthere

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

---

:eh: 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?

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

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

Quote:

---

Originally Posted by Ao1

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

Quote:

---

Originally Posted by 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.

---

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.

Quote:

---

Originally Posted by 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

---

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.

Quote:

---

Originally Posted by Ao1

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

Quote:

---

Originally Posted by overthere

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

Quote:

---

Originally Posted by zanzabar

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

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 :(

Quote:

---

Originally Posted by overthere

...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. :shrug:

Quote:

---

Originally Posted by 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

---

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.

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.

Quote:

---

Originally Posted by Ao1

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

Quote:

---

Originally Posted by Ao1

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

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. :up: I should empathise “start” as a lot of things still seem to be going over my head :shakes:

Quote:

---

Originally Posted by alfaunits

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

---

OK, thanks.

Quote:

---

Originally Posted by alfaunits

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

---

That would be my assumption as well. (we'll probably never get to know what really happens :))

For most controllers this is not an issue at all. (flagging pages as available and leaving data intact)

For the SF controller however, it is.
The compression part of the controller paired with the fact that data is deduplicated makes a difference.
If a "root" file (a base file or data that deduplicated data is based upon) is deleted there would be additional house-keeping for the controller.
So, in case of the SF controller I have to assume that the TRIM command is acted upon and it results in more than just flagging the page(s) as free.

Quote:

---

Originally Posted by alfaunits

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.

---

Technically speaking, a TRIM command does not mark a page free.

From the operating system perspective (at least for the Windows OS), control I/O operations (specifically "Device Control" I/O operations) that specify "Manage Data Set Attributes (MDSA)" requests can specify a "TRIM" action.

A MDSA TRIM action request I/O operation specifies a particular set of logical blocks (i.e., sectors) upon the SSD that are to be "trimmed"; this specific set of blocks is indicated by means of a "Data Set Range (DSR)". A DSR identifies the starting offset (i.e., essentially the starting block address for the particular set of blocks) along with the overall combined length of the blocks. In addition, a single MDSA TRIM I/O operation can specify one or more DSRs.

Now down at the device level, the corresponding device command (at least for the ATA/ATAPI specification standard the last time I looked at it) also uses a similar data structure that is called a "LBA Range Entry" (which specifies a starting Logical Block Address (LBA) value along with a "Range Length" for each LBA Range that is to be "trimmed").

As you know, devices (SSD as well as HDD) are essentially seen by file systems as being composed of addressible "blocks". File systems in general do not know about flash memory "pages" or "erase blocks" (unless the file system was specifically implemented with intimate knowledge of the underlying physical media) - nor should they know about such things if they are to remain independent of the intricacies of the underlying physical media.

So overall, a TRIM command (at least those that I have seen) specifies a set of logical blocks/sectors, which may be contained within one (or more) pages (and corresponding erase blocks) within the actual flash media.

In any case, I believe that you are correct that a given TRIM command does not necessarily entail an immediate "erase block" action, which (if appropriate) can be performed subsequently at some later time by the device.

Quote:

---

Originally Posted by alfaunits

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

---

I looked again at the test that you mentioned. It is an interesting test.

Two things immediately come to mind:

1. I understand that TRIM support is reported as enabled, but it would be helpful if you verified that TRIM commands were actually being generated and issued to the device. This might also confirm whether the eSATA port is in fact an issue (i.e., preventing TRIM commands from being passed to the device).
   
   
2. Given that the TRIM commands were successfully generated and issued, it is still possible (and apparently valid) for the "trimmed" data to be subsequently returned effectively unchanged.
   
   This possibility stems from the ATA/ATAPI specification standard itself, more specifically the current settings of the IDENTIFY DEVICE data word associated with the DATA SET MANAGEMENT command (please see my prior post #21).
   
   For example, one of the IDENTIFY DEVICE settings states that the data returned by a read command for a trimmed LBA range may be set to "any value" (which, as least to me, allows for the possibility that the data can be returned unchanged). BTW, another of the IDENTIFY DEVICE settings states that the returned data shall be cleared to zero. So what is returned can be dependent upon what the device indicates within its IDENTIFY DEVICE settings.
   
   A key concept regarding TRIM as I understand it is that "a trimmed block is not necessarily an erased (or zeroed) block". A TRIM command is simply a notification to the device that the respective block(s) are considered by the file system to no longer contain valid data. What the device does to the trimmed blocks (and when) is up to the particular device implementation (and in accordance with the ATA/ATAPI standard regarding what is returned for trimmed blocks).

As usual nothing is straight forward with storage.

Maximum LBA Range Supported Proposal ATA8-ACS2 – April 2009 Revision 64

7.10.3.2 Trim

When Trim is set to one, the data in the logical blocks specified by the DATA SET MANAGEMENT command’s output data shall meet the following requirements then:

a) if word 69 bit 14 of the IDENTIFY DEVICE data is set to one, then once a trimmed LBA has been read (e.g., a read command), the data in that logical block becomes determinate (i.e., all read commands to a logical block shall return the same data until a subsequent write command to that logical block successfully completes); or

b) if word 69 bit 14 of the IDENTIFY DEVICE data is cleared to zero, then the data read is indeterminate. The data read from an LBA that has been trimmed shall not be retrieved from data that was previously received from an application client addressed to any other LBA.
Once a trimmed LBA has been written ( e.g., a write command or a SECURITY ERASE UNIT (command), the data in that logical block becomes determinate. (i.e., the logical block contains the written data.).

Trim shall not add or remove LBAs from the NV Cache Pinned Set.

http://www.anandtech.com/show/2738/10

When you delete a file, the OS sends a trim command for the LBAs covered by the file to the SSD controller. The controller will then copy the block to cache, wipe the deleted pages, and write the new block with freshly cleaned pages to the drive.

With TRIM, if you delete a file, the OS sends a TRIM command to the drive along with the associated LBAs that are no longer needed. The TRIM command tells the drive that it can schedule those blocks for cleaning and add them to the pool of replacement blocks.

http://en.wikipedia.org/wiki/TRIM

Because of the way that file systems typically handle delete operations, storage media (SSDs, but also traditional hard drives) generally do not know which sectors/pages are truly in use and which can be considered free space. Delete operations are typically limited to flagging data blocks as "not in use" in the file system.[5][6] Contrary to, for example, an overwrite operation, a delete will therefore not involve a physical write to the sectors that contain the data. Since a common SSD has no access to the file system structures, including the list of unused clusters, the storage medium thus remains unaware that the blocks have become available. While this often enables undelete tools to recover files from traditional hard disks,[6][7]despite them being reported as "deleted" by the operating system, it also means that when the operating system later performs a write operation to one of the sectors, which it considers free space, it effectively becomes an overwrite operation from the point of view of the storage medium. For traditional hard disks this is no different from writing an empty sector, but because of how some SSDs function at the lowest level, an overwrite produces significant overhead compared to writing data into an empty page, potentially crippling write performance.[6]

http://techgage.com/article/too_trim..._is_impossible

TRIM is a brand-new ATA command that the OS will issue to the SSD when a certain request is made, such as Delete, Format or Discard. What it does is rather simple, but it's immensely helpful. When you either delete a file, or format the entire SSD, TRIM will purge both the data and the link to it, so in essence, it's gone. There is no trickery, or any advanced algorithms being used to wipe the block clean... it's simply cleaned, and left in a ready-to-use state.
One of the more overlooked aspects of TRIM, as amazing and helpful as the command is, is that once it's issued, your chance of data recovery has essentially gone to 0


So.....at a basic level:

A delete operation occurs on the OS side only it does not generate a physical write.

When the OS needs to write to an area it has marked as “deleted” it simply overwrites the physical data, which is not a performance problem with HDD.

With SSD it is a performance problem, so a process is required to physically delete data in advance of the normal process where data is simply overwritten rather than being deleted first.

The SSD itself does not know what is valid or invalid data so TRIM has to indentify invalid data to the SSD to provide the SSD with the option to do something about it i.e. wipe invalid data before it gets overwritten with new data.

Have I at least got the basics right?

Also would I be right to say that a quick format issues a TRIM command that wipes all data from the SSD? (Unlike what happens with HDD)

Quote:

---

Originally Posted by Ao1

As usual nothing is straight forward with storage.

Maximum LBA Range Supported Proposal ATA8-ACS2 – April 2009 Revision 64

7.10.3.2 Trim ...

http://www.anandtech.com/show/2738/10

When you delete a file, the OS sends a trim command for the LBAs covered by the file to the SSD controller. The controller will then copy the block to cache, wipe the deleted pages, and write the new block with freshly cleaned pages to the drive.

With TRIM, if you delete a file, the OS sends a TRIM command to the drive along with the associated LBAs that are no longer needed. The TRIM command tells the drive that it can schedule those blocks for cleaning and add them to the pool of replacement blocks.

http://en.wikipedia.org/wiki/TRIM

... Since a common SSD has no access to the file system structures, including the list of unused clusters, the storage medium thus remains unaware that the blocks have become available. While this often enables undelete tools to recover files from traditional hard disks,[6][7]despite them being reported as "deleted" by the operating system, it also means that when the operating system later performs a write operation to one of the sectors, which it considers free space, it effectively becomes an overwrite operation from the point of view of the storage medium. For traditional hard disks this is no different from writing an empty sector, but because of how some SSDs function at the lowest level, an overwrite produces significant overhead compared to writing data into an empty page, potentially crippling write performance.[6]

http://techgage.com/article/too_trim..._is_impossible

TRIM is a brand-new ATA command that the OS will issue to the SSD when a certain request is made, such as Delete, Format or Discard. What it does is rather simple, but it's immensely helpful. When you either delete a file, or format the entire SSD, TRIM will purge both the data and the link to it, so in essence, it's gone. ... One of the more overlooked aspects of TRIM, as amazing and helpful as the command is, is that once it's issued, your chance of data recovery has essentially gone to 0

---

Several comments (some of which tie-in to comments that I had meant for the prior post #22 by Ao1):

Maximum LBA Range Supported Proposal ATA8-ACS2 – April 2009 Revision 64

I believe that there is a subsequent revision of this proposal to be found within a draft "ATA/ATAPI Command Set - 2 (ACS-2)" document (T13/2015-D, dated August 2009?) that introduces a further qualification of the word 69 bit 14 of the IDENTIFY DEVICE data word. This qualification basically specifies that if the IDENTIFY DEVICE data word 69 bit 5 is set to one, then the data returned by a read command shall be cleared to zero, and if the IDENTIFY DEVICE data word 69 bit 5 is cleared to zero, then the data returned by a read command may be set to any value.

It is this additional qualifier that I was alluding to within my prior post #29.

Anandtech.com Article Excerpts

The first excerpt seems to suggest that the SSD controller will immediately perform the flash management operations (e.g., ".. wipe the deleted pages...") as part of its processing the TRIM command.

I noticed within the same article at the Anandtech.com URL the following statement made as part of an example depiction of "how TRIM works":

"The TRIM command forces the block to be cleaned before our final write."

On the other hand, the second excerpt states that "The TRIM command tells the drive that it can schedule those blocks for cleaning and add them to the pool of replacement blocks."

So in the first case (and maybe this is the point that you are implying) there seems to be a suggestion that any flash management tasks are performed immediately by the SSD as part of processing the TRIM command, yet the second excerpt indicates that the TRIM command allows for some "scheduling" to be done for the flash management tasks.

From my understanding (and not to belabour the point), the TRIM command does neither (i.e., it does not instruct the SSD as to when, much less how, any flash managment tasks are to be performed by the device). The TRIM command simply notifies the device that the specified LBAs do not contain any "valid" data (from the perspective of the host / file-system).

Now I mean no disrespect to the folks at Anandtech.com (or to other published reviewers of SSDs). The referenced Anandtech.com article has a date of March 2009, which was before actual SSD usage became more widespread upon desktop/laptop systems (so that we could see how these devices actually operate in everyday usage).

I also understand that these reviewers are trying to "simplify" the technology (which can be quite complex in actual detail) and present it in more layman terms. But the good news is that Forums like this one are available to help "clarify" how things (actually, or should I say "technically") work in greater detail! :)

WIKI TRIM url

One thing that I would like to point out within this Wiki explanation of TRIM is the following excerpt:

... Since a common SSD has no access to the file system structures, including the list of unused clusters, the storage medium thus remains unaware that the blocks have become available...

I believe that this statement is basically true, which is why I was/am puzzled by the Intel statement that Ao1 included within his post #22:

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

What I find puzzling is the reference to "does a file system compare". How does an SSD controller - which has no access to the file system structures per se - perform a "file system compare"?

Certainly the SSD controller could attempt, for instance, to interrogate what it believes are file system metadata structures (e.g., a bitmap) present within the flash media, but this I believe is a very risky approach. This is especially the case if the actions of the SSD controller are not carefully synchronized with the respective file system itself, including the direct guidance and approval by the file system, otherwise data corruption/integrity issues may well arise.

Techgage.com Article Excerpts

Although it's a more recent article (March 2010), this article also seems to suggest that the TRIM command entails an immediate flash management operation (i.e., "... TRIM will purge both the data and the link to it, so in essence, it's gone.") rather than simply being a "notification" mechanism.

The other portion of this excerpt (i.e., that once the TRIM command is issued, "your chance of data recovery has essentially gone to 0") appears to coincide to some degree with Ao1's concerns about "the possibility of not being able to recover data is (for me) a downside to SSD" as mentioned in his post #22.

It seems to me that two important factors to consider in this regard are:

1. Firstly, the constraints imposed by the IDENTIFY DEVICE data word as mentioned above. That is, even if the data contents of a trimmed sector remained unchanged (e.g., not subject to a flash management action such as an "erase block"), the data returned by the device would apparently be subject to the settings that it has indicated within the TRIM-related IDENTIFY DEVICE data word (which could mean that the device always returns all zeroes for trimmed sectors until these sectors are overwritten).
   
   
2. Assuming that the IDENTIFY DEVICE settings allow for the device to return unchanged the data contained within a trimmed block/sector, there is also a "timing" issue to consider. That is, whether the device performs a flash management action (such as an "erase block") upon the trimmed sector before some "undelete" program can "recover" the deleted data.
   
   Of course, this "erasure" phenomenon is applicable only to trimmed blocks/sectors and SSDs (and not HDDs), so it is something new to be considered when using SSDs in comparison to HDDs.

And for the sake of completeness, it should be mentioned that both SSD and HDD are subject to the scenario where the file system "overwrites" a block/sector (whether trimmed or not for SSDs) that previously contained valid data for a file that was subsequently deleted, and where this "overwrite" occurs before some "undelete" program can "recover" the deleted data.

In any case, regarding the overall issue of comparing "unrecoverable data" risks between HDD and SSD in general, I defer to the JEDEC folks and other data recovery and device reliability experts who are more versed in this complicated issue.

OK, I think I’m getting it now, but now I’m puzzled by how GC works. If the storage medium remains unaware that the blocks have become available (without a TRIM command) how does the GC process know what blocks to clean? There seems to be a range of how effective GC is between different controllers so there must be different mechanisms to how it is achieved.

I am also puzzled by what Intel mean when they say their SSD’s are “very resilient to dirty pages”.

By the way later in that Techgage article I linked earlier they try unsuccessfully to recover data after a TRIM command. They were only using basic data recovery programs, but before TRIM they had no problem getting the data back.

Quote:

---

Originally Posted by Ao1

OK, I think I’m getting it now, but now I’m puzzled by how GC works. If the storage medium remains unaware that the blocks have become available (without a TRIM command) how does the GC process know what blocks to clean? There seems to be a range of how effective GC is between different controllers so there must be different mechanisms to how it is achieved.

---

GC cannot mark those pages free, so as far as it is concerned they are used without the TRIM. GC can only work with pages marked as free.
GC can only merge two partially-used blocks into a new fully used block (thus providing one more free block). This would also be part of wear leveling (the new block would not be the same as the two partially used block).
How exactly this works in the algorithm is way more complex, but is all that GC can do essentially. (maybe something more for SandForce controllers because of compression, but I doubt the compression can surpass a page boundary - it would be extremely time intensive then).

Quote:

---

I am also puzzled by what Intel mean when they say their SSD’s are “very resilient to dirty pages”.

---

Maybe they have more free space and a better algorithm. Nothing else comes to my mind. I doubt they can compare the file system bitmap (they can't be sure which FS is on disk).

Quote:

---

By the way later in that Techgage article I linked earlier they try unsuccessfully to recover data after a TRIM command. They were only using basic data recovery programs, but before TRIM they had no problem getting the data back.

---

Cool! That's what I was hoping for - gotta check it out.
EDIT: Just read. They used Intel X25-M essentially, interesting. I gotta test with my X25-M if I can (it's boot drive - I don't like firmware upgrading it).

You might want to wait. There is a new f/w version coming out Jan 3rd for the G2's. The new version will be 02M3. Nothing to get excited about though as it is described as an incremental improvement.

EDIT:

So it seems the chances of getting anything back after a delete is at best remote, especially if you accidently format the drive (assuming TRIM is working). If the controller fails, which seems to be the case of most if not all failures, you have no chance of getting the data back.

If risk is considered as a factor of consequence and likelihood of occurrence a single SSD with TRIM would have to rank as the worst non-volatile storage solution possible in terms of being able to recover data.

Here I delete a file from a recently formatted HDD & SSD and compare what happens with a hex editor. The SSD was in a TRIM enabled environment. I did not run a manual trim, but assume the drive was auto trimmed when the recycle bin was emptied.

I think the MFT keeps a record of the file, but the record refers to nothing but x00. Either way the data is gone.

Now for HDD

I'm guessing 160GB G2 Intel in there? That is what I would expect to happen on an SSD if TRIM works correctly, but it does not on every SSD :(

Quote:

---

Originally Posted by Ao1

I think the MFT keeps a record of the file, but the record refers to nothing but x00. Either way the data is gone.

---

Sounds like your SSD might have the IDENTIFY DEVICE data word 69 bit 5 set to one (in which case the data returned by a read command "shall be cleared to zero"; please see post #31 above). I have heard folks who are currently working on the device protocol standards call this the "RZAT" bit/function (i.e., "Return Zero After TRIM").

When the RZAT bit is set, the device will continue to return such zeroes forever (that is, until the respective trimmed blocks/sectors are written to by the host).

Please note that also in this case the "trimmed" data can still actually exist unchanged within the flash media (at least until, for example, if/when the device decides to "erase" the respective data from the flash media as part of its Garbage Collection processing).

Overall, there are various security, flash-endurance, and other issues related to how "trimmed" blocks are handled.

Hi overthere :)

That fits well with what I could observe. I forgot about the return zero read command. (Must pay more attention :shakes: )

Is it possible to use a hex editor to reverse the RZAT setting and get the file back? (Assuming the device has not subsequently deleted the data).

EDIT:

Hi alfaunits, yes it was the trusty X25-M.

Quote:

---

Originally Posted by Ao1

Is it possible to use a hex editor to reverse the RZAT setting and get the file back? (Assuming the device has not subsequently deleted the data).

---

Hi Ao1 :)

I suspect/believe that the RZAT "feature/support" is not a configurable option (the standards specifications would need to be checked to confirm).

The RZAT setting value mentioned is included within the information (regarding optional feature or command support provided by the device) returned to the host in response to a IDENTIFY DEVICE command.

I suppose a SSD vendor could have a vendor-specific configuration utility for modifying the RZAT support, but that's probably unlikely for general distribution.