On Tue, 10 Nov 2009, Tim Cook wrote:
My personal thought would be that it doesn't really make sense to
even have it, at least for readzilla. In theory, you always want
the SSD to be full, or nearly full, as it's a cache. The whole
point of TRIM, from my understanding, is to speed up the drive by
zeroing out unused blocks so they next time you try to write to
them, they don't have to be cleared, then written to. When dealing
with a cache, there shouldn't (again in theory) be any free blocks,
a warmed cache should be full of data.
This thought is wrong because SSDs actually have many more blocks that
they don't admit to in their declared size. The "extreme" or
"enterprise" units will have more extra blocks. These extra blocks
are necessarily in order to replace failing blocks, and to spread the
write load over many more underlying blocks, and thereby decrease the
chance of failure. If a FLASH block is to be overwritten, then the
device can reassign the old FLASH block to the spare pool, and update
its tables so that a different FLASH block (from the spare pool) is
used for the write.
Logzilla is kind of in the same boat, it should constantly be
filling and emptying as new data comes in. I'd imagine the TRIM
would just add unnecessary overhead. It could in theory help there
by zeroing out blocks ahead of time before a new batch of writes
come in if you have a period of little I/O. My thought is it would
be far more work than it's worth, but I'll let the coders decide
that one.
The "problem" with TRIM is that its goal is to decrease write latency
at low/medium writing loads, or at high load for a short duration. It
does not do anything to increase maximum sustained write performance
since the maximum write performance then depends on how fast the
device can erase blocks. Some server environments will write to the
device at close to 100% most of the time, and especially for
relatively slow devices like the X25-E.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
