Verifying TRIM functionality

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.