On Fri, Aug 14, 2009 at 8:38 PM, Chris Worley<worleys@xxxxxxxxx> wrote: > On Fri, Aug 14, 2009 at 6:30 PM, Greg Freemyer<greg.freemyer@xxxxxxxxx> wrote: >> On Fri, Aug 14, 2009 at 8:19 PM, Chris Worley<worleys@xxxxxxxxx> wrote: >>> On Fri, Aug 14, 2009 at 5:45 PM, Matthew Wilcox<matthew@xxxxxx> wrote: >>>> On Fri, Aug 14, 2009 at 05:21:32PM -0600, Chris Worley wrote: >>>>> Sooner is better than waiting to coalesce. The longer an LBA is >>>>> inactive, the better for any management scheme. If you wait until >>>>> it's reused, you might as well forgo the advantages of TRIM/UNMAP. If >>>>> a the controller wants to coalesce, let it coalesce. >>>> >>>> I'm sorry, you're wrong. There is a tradeoff point, and it's different >>>> for each drive model. Sending down a steady stream of tiny TRIMs is >>>> going to give terrible performance. >>> >>> Sounds like you might be using junk for a device? >>> >>> For junk, a little coalescing may be warranted... like in the I/O >>> schedular, but no more than 100usecs wait before posting, or then you >>> effect high performing devices too. >>> >>> Chris >> >> Why? >> >> AIUI, on every write a high performing device allocates a new erase >> block from its free lists, writes to it, and puts the now unused erase >> block on the free list. > > So erase blocks are 512 bytes (if I write 512 bytes, an erase block is > now freed)? Not true. Seriously, how do you know? Are you under NDA? The write paper I read about typical SSD design described a partial erase block write as: Internal logic/micro-controller performs: Read erase block, modify erase block, allocate new erase block, write new erase block, free now unused old erase block, old erase block added to a hardware erase queue the performs the actual erase in the background at the relatively slow speed of multiple milliseconds.. The purpose of the trim/discard command being to allow the ssd to have enough free erase blocks ready to go that the writes don't have to stall while they wait for a erase block to pop out of the erase queue. Greg -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
