Verifying TRIM functionality

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