Re: Is TRIM/DISCARD going to be a performance problem?

[Theodore Tso <tytso@mit.edu>]

On Mon, May 11, 2009 at 09:10:15AM -0400, Greg Freemyer wrote:
> 
> That implies that the SSD folks are not treating erase blocks as a
> contiguous group of sectors.  

Correct. 

> For some reason, I thought their was
> only one mapping per erase block and within the erase block the
> sectors were contiguous..

No, if you try to treat erase blocks as a contiguous group of
sectors, you'll have terrible write amplification problems (leading to
premature death of the SSD) and terrible small random write
performance.  Flash devices optimized for digital cameras might have
done that, but for SSD's, this will result in catastrophically bad
performance, and very limited lifespan.  As I said, I expect these
SSD's to be weeded out of the market very shortly.

For any sane implementation of an SSD, the mapping will be on a per
LBA basis, not on a per-erase block basis.

> More realistic is to figure out a way to make it deterministic at
> least for the short term (by writing data to all the trimmed blocks?),
> then reshaping, then having a tool to scan the filesystem and re-issue
> all the trim commands.

Writing data to all of the trimmed block?  Um, no.  That would be a
diaster, since it accelerates the wear and tear of the SSD.  The whole
*point* of the TRIM command is to avoid needing to do that.

The whole worry about determinism is highly overrated.  If the
filesystem doesn't need a block, then it doesn't need it.  What you
read after you send a TRIM command, whether it is the old data because
the device applied some kind of rounding, or random data, or all
zero's, won't matter to the filesystem.  Why should the filesystem
care?  I know I certainly don't....

					- Ted