Messages in this thread | | | Date | Tue, 25 Nov 2008 10:15:31 +0100 | From | Jens Axboe <> | Subject | Re: about TRIM/DISCARD support and barriers |
| |
On Mon, Nov 24 2008, Matthew Wilcox wrote: > 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).
It's completely parallel to normal fs merges, I think it's a good fit. And it's not like there are a lot of drivers to check for this particular command type.
> 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.
If need be, then we can just add a setting for that like we have for request sizes, segments, etc.
> 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.
Irk, that sounds pretty horrible and slow...
-- Jens Axboe
| |