On 05/11/2009 10:27 AM, Theodore Tso wrote:
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
The key is not at the FS layer - this is an issue for people who RAID these
beasts together and want to actually check that the bits are what they should be
(say doing a checksum validity check for a stripe).
ric
--
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
