Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am writing a script and I have a few questions about the inner workings of the TRIM command. If TRIM is issued for an entirely empty (zeroed) erase block, does the garbage collector still delete the block? I would like to be able to issue TRIM for large blocks on the ssd, but my concern is that this would lead to unnecessary wear on blocks that are already empty.

On the other hand, if I don't issue TRIM on empty blocks that were previously used by the filesystem (say, parts of a file that contained only zeros), is there any overhead when writing meaningful data to these blocks? In other words, is the ssd "smart" enough to not perform a read-modify-write cycle since the block is already in its "ground" state?

Is this controller dependent (I mostly care about the new sandforce)?

share|improve this question
    
Do You want to manually issue a trim command? How can this be done and why don't You leave it to the operating system? –  Black Feb 7 '12 at 7:11
    
A script for doing what? –  Giovanni Toraldo Feb 7 '12 at 7:19
    
I am using raid 0 and the script is for trimming the raid array (mdadm). –  Ivan Feb 7 '12 at 17:57

2 Answers 2

up vote 1 down vote accepted

Justin Lynn's answer is entirely correct. I just wanted to address another part of you question.

Due to the way NAND cells store data, the erased (ground) state is a one, not a zero. So a block of zeros needs to be erased before it can be written to, but a block of ones can be written to directly.

EDIT: As for the question of what happens when the SSD needs to write to a block that is filled with ones is harder to answer. Even if there is no data in the block that needs to be erased there may still be metadata that needs to be erased. If that isn't the case and the block is completely writable it depends on the GC implementation of the SSD.

Another possibility is that the SSD is smart enough that when you write a zero-filled LBA to it, it realizes that there is no need to write the data to NAND. Instead it just unmaps the LBA and when asked for the data it returns zeros, as a default for unmaped LBAs. I wouldn't be suprised if SandForce drives do this since they are already doing data compression and deduplication. If other SSDs do this I don't know.

I realize there are a lot of possibles, maybes and don't knows in my answer, but there are no general rules about this an SSD maker has to follow so it is up to individual makers to decide. The people privy to these decisions can't talk about them since the specific implementations of these GC algorithms are so crucial to SSD performance.

share|improve this answer
    
I believe the logical bits are inverted from the physical ones. If you restore a drive with safe erase or whatever, and run hexdump, you'll see only 0's. One of my questions is actually about whether a block of zeros (or physical 1's) which was previously used and released by the filesystem will be written directly to, although the drive thinks it still contains non-trivial (i.e. used in a file) data. –  Ivan Feb 7 '12 at 18:02
    
There may be some drives where the logical bits are inverted, but I'm not aware of any. OTOH in the pre-TRIM days there were some SSD makers recommending writing 0xFF fill to empty space, as a poor mans TRIM. The facts that you read zeros after a secure erase doesn't tell you anything because it unmaps the LBA-to-page mappings, so when you run the hexdump the drives isn't reading the NAND at all, its just generating zeros and returning them. –  Mr Alpha Feb 7 '12 at 19:33
    
Thanks, this was very helpful. –  Ivan Feb 7 '12 at 21:15

Well, TRIM as a command simply tells the SSD controller that the block is no longer required by the file system and that the controller may not worry about the block any longer when it is garbage collecting free flash space. Otherwise the SSD would have to move the [now deleted] block around while garbage collecting. TRIMing large blocks of zeros shouldn't increase wear on the drive, quite the opposite, on controllers with a proper TRIM implementation. That said, the exact behavior is controller dependent, but for the purposes of your usage, I wouldn't worry about TRIMing large zero block areas, if anything, you'd be saving the SSD from having to copy around blocks of zeros while it GCs. I'm no expert of the SATA protocol, but it seems like a pretty clear conclusion from reading http://en.wikipedia.org/wiki/Write_amplification , especially http://en.wikipedia.org/wiki/Write_amplification#TRIM .

share|improve this answer
    
TRIM does more than just tell the GC not to move TRIMmed blocks. Those blocks, since they once contained meaningful data, will have to be reset to zero by the GC at some point. If the blocks are already in their ground state (logical 0/physical 1), does the GC still attempt to erase them or does it recognize there is no need? –  Ivan Feb 7 '12 at 18:09

Your Answer

 
discard

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.