Allocating uninitialized file blocks

Posted Apr 20, 2012 21:39 UTC (Fri) by dlang (guest, #313)
In reply to: Allocating uninitialized file blocks by Cyberax
Parent article: Allocating uninitialized file blocks

unfortunately trim is not a fast command for many drives

Allocating uninitialized file blocks

Posted Apr 20, 2012 21:45 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

That depends. TRIM-ing 100Gb of data on my Intel SSD-based RAID takes little more than 2-3 seconds, it's way faster than writing zeros directly and more flash-friendly.

However, TRIM command can't be queued. So it probably makes no sense to use it for large allocations and/or to keep a pool of recently-trimmed pages for immediate small allocations.

Allocating uninitialized file blocks

Posted Apr 20, 2012 21:51 UTC (Fri) by dlang (guest, #313) [Link]

the fact that it can't be queued is a major performance hit.

The SSD does keep a pool of unused pages for new allocations. What trim does is it lets the SSD know that you no longer care about the data on that block, and so it can add the block back to that pool.

If the SSD runs out of this pool, writing slows drastically as it must first erase a block before it can write anything. If you are expecting to do a LOT of writing to a SSD, you may want to make sure that you partition it to something less than the advertised size so that that extra space will remain in the pool (this works as long as that extra space has never been written to, or is explicitly relased via a TRIM command)