Several comments (some of which tie-in to comments that I had meant for the prior post #22 by Ao1):Originally Posted 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:
- 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).
- 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.
Reply With Quote
Bookmarks