Re: about TRIM/DISCARD support and barriers

[Matthew Wilcox]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/