On Wed, Nov 11, 2009 at 11:51 AM, Bob Friesenhahn < bfrie...@simple.dallas.tx.us> wrote:
> 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. I'm well aware of the fact that SSD mfg's put extra blocks into the device to increase both performance and MTBF. I'm not sure how that invalidates what I've said though, or even plays a roll, and you haven't done a very good job of explaining why you think I'm wrong. TRIM is simply letting the device know that a block has been deleted from the OS perspective. In a caching scenario, you aren't deleting anything, you're continually over-writing. How exactly do you foresee TRIM being useful when the command wouldn't even be invoked? > > > 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. > Right... you just repeated what I said with different wording. --Tim
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
