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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
