On Mon, Nov 24, 2008 at 09:03:50AM +0000, David Woodhouse wrote: > And _then_ we can think about special cases which let us merge > non-contiguous discards. I've been thinking about what a solution would look like that lets us send non-contiguous discards down, and I don't like the look of any of them. Right now, discard bios get turned into discard requests and those are handled by the block device drivers as being a discard of the range (sector, sector + nr_sectors). If we're going to allow discontiguous ranges to be merged into one request, then we need somewhere to store the ranges. The obvious answer is in the ->bio list. But then, an unconverted driver will discard the wrong sectors (presuming nr_sectors gets updated to the length of all discarded sectors). There's also murmurings from vendors that they want to restrict the number of ranges transmitted in a single UNMAP/TRIM command, and that's more information to be passed to the elevator. How about an interface that lets the driver's discard function scan back through the queue and see if there are any more discard bios queued up? If there are, (and it has room for them) it can retire them from the queue early. I'm open to other ideas, of course. -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- 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
