• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

How does Anandtech manually TRIM their drives?

ikjadoon

Senior member
From the Plextor M3 Pro Review (http://www.anandtech.com/show/5851/plextor-m3-pro-256gb-review/8),

"Finally I TRIM'ed the drive to make sure that TRIM functions properly, and it does:"

How did Mr. Vättö manually TRIM it (i.e. tell the drive to go ahead and delete the marked pages)? Did he mean "secure erase"?

I Google'd around and there was ForceTrim by OCZ, but I can't seem to access the topic (http://www.ocztechnologyforum.com/f...Here-s-a-tool-to-force-TRIM-your-entire-drive) at OCZ's forums ("your account does not have the correct user permissions"). Some people said CCleaner can also manually TRIM?

I have a Plextor M3S (LITE-ON OEM of the M3 Pro).
 
If I understand correctly Windows 7 will send a TRIM command for the entire drive when you format it.

So I would speculate that likely it is simply being formatted.
 
you can use certain programs to issue a trim command whenever you want.

I only know about linux, where I can use fstrim -v /
windows likely has something similar
 
Formatting != trim, although formatting will cause a TRIM command to be sent.

TRIM commands should be sent whenever your recycle box is emptied. This will irrevocably erase your (already deleted) data on your SSD.
 
Last edited:
Formatting != trim, although formatting will cause a TRIM command to be sent.

TRIM commands should be sent whenever your recycle box is emptied. This will irrevocably erase your (already deleted) data on your SSD.
Reason: clarification: emptying your recycle bin will not clear your data on your SSD....
It doesn't matter how many times I read this post, it still doesn't make sense.
 
It doesn't matter how many times I read this post, it still doesn't make sense.

There are two statements in the post, plus the "reason/clarification". The way I understand it is:

a) Format (or delete partition) results in a trim for all the chunks in the partition to be returned to the game by using the proper TRIM command(s).

b) A file delete results on TRIM command(s for the allocated chunks. Since Windows postpones delete by means of the Recycle Bin facility, the TRIMs will be issued when the Recycle Bin is emptied.

I am not sure the TRIM is supposed to clear the released blocks or not.
 
The file system knows the sectors which are no longer allocated. The ATA TRIM command is associated with a string of LBAs to inform the drive what to erase, and the SSD typically does this only when an entire block of sectors are flagged with the TRIM command.

The ATA Secure Erase command will obliterate all sectors on a drive, whether they have LBA's or not.
 
Last edited:
It doesn't matter how many times I read this post, it still doesn't make sense.

In windows, if you delete a file, Windows flags the file as "deleted", but moves it (flags it) to the recycle bin; it is not actually deleted. Emptying the recycle bin actually deletes the file, and then it issues a TRIM command.

The part about irrevocable deletion is a result of the tech involved; with platter based drives, there is no TRIM needed, and thus whenever your recycle bin is emptied, the HDD only erases the file entry in the Master File Table; ie, the information you would need to find it. You can still undelete it. With an SSD, while the delete command also deletes the MFT entry, the TRIM command that's sent with the delete command clears the actual block data - meaning your data is actually gone. You can't undelete because the data isn't just lost, it's been overwritten.
 
Also if you have Windows set to empty the recycle bin immediately, simply deleting the file should TRIM the areas covered by the file too.
 
How did Mr. Vättö manually TRIM it (i.e. tell the drive to go ahead and delete the marked pages)? Did he mean "secure erase"?

I Google'd around and there was ForceTrim by OCZ
That is something only those privy to AnandTech's testing can truly answer, hopefully one of them will read your post and spare a minute to post the answer. 🙂

IIRC Forcetrim just allocates a big file just through the use of metadata, i.e. not actually writing the file, deletes it and relies on the OS sending the trim command after delete.


windows likely has something similar
Not so sure about that, IIRC W7 doesn't like trim commands being sent from userland that involve the filesystem, on the other hand Vista will be happy with perhaps just Admin privledge.


TRIM commands should be sent whenever your recycle box is emptied. This will irrevocably erase your (already deleted) data on your SSD.
Not erased, unmapped.


The file system knows the sectors which are no longer allocated. The ATA TRIM command is associated with a string of LBAs to inform the drive what to erase, and the SSD typically does this only when an entire block of sectors are flagged with the TRIM command.

The ATA Secure Erase command will obliterate all sectors on a drive, whether they have LBA's or not.
Right, as erasing is done on the block level, not the page level it would be silly to erase the whole block containing many other allocated pages or perhaps even containing many pages that have not been written to yet, unless in dire straights where every free page is crucial (lack of pages in free pool) and you don't really want to be in that situation if possible.


With an SSD, while the delete command also deletes the MFT entry, the TRIM command that's sent with the delete command clears the actual block data - meaning your data is actually gone. You can't undelete because the data isn't just lost, it's been overwritten.
The MFT entry is flagged not deleted and stays there until overwritten. The file data outside of the MFT isn't overwritten unless another file is written to the same logical LBA's It's LBA's are instead no longer mapped to the previous SSD pages.


Also if you have Windows set to empty the recycle bin immediately, simply deleting the file should TRIM the areas covered by the file too.
Or just use the shift button with delete to bypass the recycle bin.
 
Not erased, unmapped.

The MFT entry is flagged not deleted and stays there until overwritten. The file data outside of the MFT isn't overwritten unless another file is written to the same logical LBA's It's LBA's are instead no longer mapped to the previous SSD pages.

Does the TRIM command not actually cause the drive to overwrite the files once the drive processes the TRIM command? If not, then isn't the TRIM command not doing its job? I thought the overwriting of a block that already has data in it was the cause of performance degradation and hence the need for TRIM, which would ask the drive to clear the data from those blocks marked as deleted.
 
Does the TRIM command not actually cause the drive to overwrite the files once the drive processes the TRIM command?

From what I've read, the timing of actual erasure of blocks is up to the firmware. The ATA TRIM command includes LBA's that are no longer referenced by the file system as containing data.

Likewise up to the firmware, is what the relationship is between physical sectors (actually cells on SSD but in this context, the thing that acts as the physical sector) and LBAs. This is constantly in flux with SSD. Whereas with HDD it's almost 100% static pairing between physical sector and logical sector (even in the case of 512e AF disks where you have 8 logical sectors per physical sector) except for bad blocks removed from use, and reserve blocks used to replace bad blocks.


If not, then isn't the TRIM command not doing its job? I thought the overwriting of a block that already has data in it was the cause of performance degradation and hence the need for TRIM, which would ask the drive to clear the data from those blocks marked as deleted.

I haven't read the details of LBA reassignment with SSD with respect to TRIM. Possibly unhelpful speculation, but I'd suspect that TRIM tells the firmware which LBA's are no longer containing file system referenced data, the firmware at that time simply removes the association between LBA and the physical sectors, and then flags blocks (clusters of cells or sectors) as needing to be erased during disk idle/garbage collection/whatever its called. I doubt that the firmware and its chips under read/write workload will bother with such a task when there are many already erased blocks with LBAs assigned, ready to be populated. Just a guess.

But otherwise your understanding is correct. The point of TRIM is to aid the firmware in identifying physical sectors (cells) to be erased before they can accept new data, because this improves performance rather than erasure occurring only immediately prior to allocation with new data.
 
Does the TRIM command not actually cause the drive to overwrite the files once the drive processes the TRIM command? If not, then isn't the TRIM command not doing its job? I thought the overwriting of a block that already has data in it was the cause of performance degradation and hence the need for TRIM, which would ask the drive to clear the data from those blocks marked as deleted.

Lets say you have a file called test.txt and the length of that file uses LBA clusters 500 to 600 outside the MFT. Now lets say for simplicity the SSD maps those LBA's to the nand pages 1000 to 1100 (assuming page and cluster size is the same). If the file is deleted and the trim command is successful the SSD now releases the mapping to pages 1000 through 1100 and this notifies garbage collection that these pages are free. These pages will remain with the written data in the SSD until the blocks that they are part of are erased. When that happens is very much firmware dependent.

If the SSD supports DRAT, Deterministic Read After Trim and ZRAT Zero Return After Trim then when trying to read those LBA's that now have no mapping to pages, then zero's will be returned by the firmware. If ZRAT is not supported the firmware might return all zero's, or all one's or possibly something else. Only when the OS writes something to those unmapped LBA's will the firmware assign pages to be mapped to them and store the data. They will unlikely be the same pages.

If instead of deleting the file you write over it then the firmware unmaps the old pages 1000 to 1100 which still hold the old data which stays in the media on the SSD until the blocks they reside on are erased by the firmware. Then the firmware maps new free pages from the free pool to those LBA's, say pages 2000 to 2100, and writes the data to those pages. Unlike this example, the real mapping is likely to get fragmented.

Trim helps to provide a bigger pool of free pages by notifying the firmware that pages previously mapped to LBA's can be freed and recycled. The bigger the free pool the more efficient the SSD can be with wear and assigning new pages when required.
 
To summarize our conclusions so far:

1) Anandtech formats the SSDs, thereby sending the TRIM command to the entire drive. ATA Secure Erase skips the TRIM step and just wipes the entire drive.

2) There is no way to "manually" TRIM (except via format or Secure Erase, described above). ForceTRIM writes large files through metadata and, well, it doesn't even matter because I can't even find it, haha.

3) When an SSD actually erases the blocks: you must empty Recycle Bin because THIS sends the TRIM command. Then, it's up to the drive's magical firmware when to decide to actually erase the blocks (usually only will do this when an entire block of sectors have been tagged with the TRIM command).

4) Lots of stuff about LBA, blocks, pages, and sectors that you may peruse on your own time because I didn't understand all of it. 😛 But, seriously, great discussion; I'm glad some people have gained some new knowledge! 🙂
 
I found this interesting also: Block Management in Solid-State Devices

SSD's behave differently in some important ways compared to HDDs, but the interface in the SSD abstracts those differences, so that the file system can use the SSD like an HDD. This may not be ideal.

The other thing is that the same drive components have completely different behaviors due to firmware, whose job is abstraction. So you're not likely to find manufacturers agreeing to eliminate abstraction, because this is how they are differentiating products, even within a given company's product line (think WDC green vs red).
 
Thanks, mates!

I appreciate the article; Pocket'd for future reading! 🙂

Mrpiggy: oh, wow, well, thanks! 😀 Nifty little thing....

Dufus: Thanks for the mirror, 🙂 Someone is reading this thread just looking for that tool, haha. ;D

~Ibrahim~
 
Back
Top