Concerns about ATA-TRIM command for SSD's

I'll keep it simple to avoid misinterpretations. When I delete a file using on a TRIM-enabled SSD, with a TRIM-aware OS (Windows 7), what will happen?

1) The SSD will copy all data in the block to a new block excluding the invalid data (invalid=deleted). It will then empty the block with the invalid data and mark it as free. The new block will logically take it place.

This action takes place immediately.

2) The SSD decides other IO is to be handled with priority and decides at its convenience when it will perform what I said in 1).

3) The SSD decides it has ample free blocks and will postpone the TRIM-command for an undetermined amount of time until it can 'clean' multiple invalid blocks.

4) The SDD can do 1-3 depending on vendor implementation and you can never be sure until you test it.

5) None of the above (but then please elaborate )

I'm trying to figure out whether TRIM is the answer to the privacy issue wear-leveling presented when TRIM was not yet available.

I'm trying to keep this discussion clear of:

- MFT related remarks
- $logfile related remarks
- Pagefile related remarks

The core issue is: is the file content gone so that it cannot be recovered.
If TRIM works as I hope it does, there is no longer a need to overwrite a file (keeping in mind that we keep the above 3 items out of the discussion).

 

Dude, you truly are a geek

I thought I was a geek, but you just might be better than me

All I know (that I remember) is that with my intel drive, I had to learn a good deal about TRIM and the features of the drivers/apps that intel has for it, and some settings to tweak. I did that, put them in place, and moved on. Everything has been working wonderfully, but I have never checked on the stuff you mention.

Got a tool or method to test? I might be up for a 'short' diversion as I wouldn't mind picking up a little more infos on SSD drives.

Sul.

 

Sorry I took so long to reply. I'll PM you with more details very soon as it's kind of late where I live now. But as you can see I do check back
I thought my question was still out there so I have come up with a very geeky testing plan that is very similar to how I test mechanical hard drives. I'd be interested to learn your results.


As I said, I'll PM you but here is what I do:

1) I make a big text file with a repeated string in it. I use a 32 KiB text file as standard. Small text files will end up in the MFT (those file are called MFT-resident). And we really don't want that.

2) I use Winhex to list all clusters this file occupies. I also take note of the MFT-record entry for that file (to check whether all metadata has been scrambled after using an erase tool).

3) Normally, I'd then zero fill these clusters with an overwrite/erase tool (not really relevant here). But with SSD's, wear leveling may very well direct those 0's to another location. So all these tools are pretty much useless EXCEPT for scrambling the MFT-record.

So, I'd skip on the zero fill and just delete the file (directly, don't put it in the recycle bin). Hold shift and then hit delete, right?

4)I'd then take a new diskimage with Winhex, navigate to the clusters the file is supposed to be in and check what is there now. You can also check the MFT-record which probably should still contain things like the orignal file name.

5)Using CCleaner, there is an option to clean the MFT. I'd use that option and then go check the MFT-record for the file again (don't fill free space as we don't want to stress the SSD and it will screw with the TRIM-investigation).

6) Finally, I'd run a text search for the string in the file on the entire SSD. All entries in the page file should be ignored. The page file shouldn't really be on the SSD. Somehow data always leaks into that.


Anyway, when having deleted the file step 3, it should really be gone presto if TRIM is put to action immediately.


And congrats on the Intel SSD, if I'd buy one I'd go Intel at the moment.

 

Sounds good. Haven't dealt much with MFT, although I sorta know what it is all about.

Sul.

 

I've installed Snagit so I can compose a pictorial of what I do. I think I can get worked out in a few hours. I'll be posting it in the upcoming week.




In case you like nerdy details haha :

I know the MFT-table cannot shrink. So deleting an MFT-record is not possible. (well, it is technically possible using a disk editor like Winhex but it is so so very dangerous).

So the MFT-cleaning tool (CCleaner) seems to allocate all free space to one big file. It has to do this because otherwise Windows will try to allocate more disk space for the MFT-table if we just keep making new records for new files.
The MFT-table is just a file so this isn't all that hard.

So with the MFT-table unable to grow the program then tries to fill MFT-records of deleted files (these records are available for new files) with garbage data. Don't really know how exactly, perhaps it uses MFT-resident file as the disk is full because of the big file it created earlier. The cleaning part thus only consists of randomly creating files until Windows says 'Hey man, my MFT is full, I can't make it larger because the disk is full too, so I can't add a record for a new file'.


Cleaning the MFT is not neccessary if you delete every single file via a secure erase tool. Such tool will rename the file to be deleted a number of times before actually deleting it.

Also, if you just don't care about MFT-meta data you don't need to clean it either. It's probably just for us geeks or criminals who name their files 'plan A to rob the bank' or something and then forget to secure delete them.

 

Nice. I am looking forward to learning something new.

Sul.