On Sun, 2009-08-16 at 12:32 -0400, Mark Lord wrote: > James Bottomley wrote: > > > > For SSDs, the FTL has to have a separate operation: erase. Now, one > > could see the correct implementation simply moving the sectors from the > > in-use list to the to be cleaned list and still do the cleaning in the > > background: that would be constant cost (but, again, likely expensive). > > Of course, if SSD vendors decided to erase on the spot when seeing TRIM, > > this wouldn't be true ... > .. > > The SSDs based upon the Indilinx Barefoot controller appear to do > the erase on the spot, along with a fair amount of garbage collection. Groan. I'm with Jim on this one: If trim is going to cost us in terms of current fs performance, it's likely not worth it. The whole point of a TRIM/UNMAP is that we're just passing hints about storage use. If the drives make us pay the penalty of acting on the hints as we pass them in, we may as well improve performance just by not hinting. Or at least it's detrimental hinting in real time. So I think we've iterated to the conclusion that it has to be a user space process which tries to identify idle periods and begin trimming. > The overhead does vary by size of the TRIM operation (number of sectors > and extents), but even a single-sector TRIM has very high overhead. So it's something like X + nY (n == number of sectors). If X is large, it still argues for batching .. it's just there's likely an upper bound to the batch where the benefit is no longer worth the cost. > Samsung also now has SSDs at retail with TRIM. > I don't have one of those here. Heh, OS writers not having access to the devices is about par for the current course. James -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
