lkml.org 
[lkml]   [2008]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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



\
 
 \ /
  Last update: 2008-11-25 10:19    [W:0.067 / U:0.364 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site