Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I was wondering if one of you can help me understand what are the SSD TRIM command actually does in Windows . To my best of knowledge, once a user deletes a file, Windows obtains the list of clusters occupied by the file and erase them from the File Allocation Table. However, the directory entry remains unchanged (filename, timestamp etc).

Since flash cell deletion is slow, SSD maintain a list of free cells it can write to first, and only once no more cells are left free, it starts deletion of cells marked for deletion. The controller doesn't know if the cell is filled with zeroes or contain something, enters the TRIM command.

If the TRIM command allows the OS to notify the controller about cells ready for deletion, once called, the controller won't just "delete" the cell, it will remove its content.

If this is true, so how does recovery on SSD works?

Thanks, at0m

share|improve this question

TRIM would do the same thing in Windows as it does in every other operating system. It's a command to the SSD (or other device that supports it), mostly just passed through as is by the operating system.

First, there are two properties of flash that are important here:

  • Reading and writing flash is fast, but erasing is slow.
  • A given block can only be erased a certain number of times before it wears out.

This is very different from magnetic media: magnetic media has no such concept as erasing (writing effectively erases what was there before), and it doesn't matter how many times you overwrite the same block (in fact, rewriting a block, if it has any detectable effect at all, is a good thing because it restrengthens the magnetic field).

The best way to use flash is using a filesystem like jffs2 or ubifs that is designed for it, takes advantage of the fact that flash can be written incrementally (though not erased incrementally) and performs wear levelling across the device (attempts to erase each block an approximately equal number of times).

But SSDs, SD cards, USB sticks, and most every other kind of flash block device doesn't let you use these flash-specific filesystems properly because there is what's called a flash translation layer in between the raw flash and the block device interface. This layer cannot be bypassed and emulates a traditional (magnetic) block device on top of the flash. It implements the necessary wear levelling by scattering virtual blocks of the emulated block device over different physical locations in a way that varies each time a block is rewritten. It also lets the virtual block device has a small block size that resembles the block size of traditional block devices (something like 512 bytes or 4096 bytes) even though the size of a physical flash erase block is much larger (usually 128KBytes).

In the simplest case, the FTL (flash translation layer) has to do the following work every time you write a block on the virtual block device, assuming a flash erase block size of 128KB and a virtual block size of 4KB:

  • Read one whole physical block (which contains 32 virtual blocks)
  • Replace the one you're writing with new contents and keep the other 31 as is
  • Erase a new flash block somewhere on the device (or take one that's already been erased recently)
  • Write this new set of 32 virtual blocks on it.

Real FTLs do a lot of smart optimizations in order to avoid having to frequently do this full-blown process, so it's not quite as bad as that makes it sound. But regardless, the FTL's job will sometime involve rewriting new copies of unrelated blocks when some other block is written.

The trouble is that this is sometimes wasted work! The FTL doesn't know which blocks are in use and which blocks are free. That's the job of the filesystem that sits on top of the virtual block device. There is no need to rewrite copies of blocks that are actually free, because nobody will care if the contents of those blocks change during the process of one of the FTL's remapping and rewriting operations. If only there was a way for the FTL to be told which virtual blocks it doesn't have to care about preserving. Well, that way exists, and it's called TRIM. TRIM will save your flash by allowing the FTL to erase and rewrite blocks less often.

Now, with this background, on to your question: how does recovery on SSD work?

Well, the filesystem that sits above the FTL shouldn't be TRIMing any blocks that it actually still needs access to, so I don't really see the relevance of the question. If the filesystem has bugs in it, then, well, recovery will mostly depend on how bad the bug it, I guess. But there's no question that, with or without TRIM, the added complexity of the FTL layer will most certainly make recovery of corruption more difficult under some cimcumstances, for example if the FTL's virtual-to-physical mapping information gets corrupt.

share|improve this answer
"if it has any detectable effect at all, is a good thing because it restrengthens the magnetic field)." - It also helps the device determine if the block is invalid, although that happens on read, the point remains I suppose. If the device is unable to write the data within the tolerence of the drive to correct errors, making a habit of reading/writting the same block can be very good for the drive. – Ramhound Apr 2 '12 at 16:48

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.