Re: [PATCH 1/5] [BLOCK] Add 'discard' request handling

[Jens Axboe <jens.axboe@oracle.com>]

On Fri, Aug 08 2008, Jens Axboe wrote:
> On Fri, Aug 08 2008, David Woodhouse wrote:
> > On Fri, 2008-08-08 at 12:30 +0200, Jens Axboe wrote:
> > > Not at all, please re-read that part. I objected to adding a strategy
> > > hook just for setting cmd type and flags for discard.
> > 
> > Ah, now I understand what you were saying. And I vacillated about that
> > too -- I actually suggested to Gilad that we didn't want it, but then
> > went ahead and did it anyway.
> > 
> > Adding the ->discard_fn hook provides two features:
> > 
> > Firstly, it allows an early 'abort' of discard requests where the device
> > doesn't support them -- there's no point in allocating the request and
> > passing it down to the device to be discarded there, when we can just
> > notice that there's no ->discard_fn and return immediately from
> > blkdev_issue_discard().
> > 
> > Secondly, it allows drivers to insert the appropriate command onto their
> > queue -- I expect that SCSI and ATA drives won't use REQ_TYPE_DISCARD,
> > just as they don't use REQ_TYPE_FLUSH. They'll use REQ_TYPE_BLOCK_PC
> > with whatever opcode is allocated for trim/punch.
> > 
> > We _could_ address those two differently -- maybe we could add a
> > QUEUE_FLAG_DISCARDS in q->queue_flags to indicate that discard requests
> > are supported, and we could make the driver 'translate' from
> > REQ_TYPE_DISCARD to whatever it actually wants to do. But that seems
> > strangely different to how we handle flushes, which is what I was basing
> > my implementation on.
> > 
> 
> Given that discard requests may become quite often issued by drivers, it
> does make sense to optimize for the case where we don't support them as
> well. So perhaps the ->discard_fn() can be tolerated, though I'd rather
> get rid of the ->issue_flush_fn instead :-)
> 
> For now, lets just go with the discard_fn, I'll update the patch again.

Actually, my memory is a bit shot, since I got rid of ->issue_flush_fn
in the 2.6.24 cycle. So it's already gone

So, instead, lets check for the appropriate queue flag in
blkdev_issue_flush() and in generic_make_request() when unrolling the
stack. The drive must then do the transformation in the ->prep_fn()
function.

-- 
Jens Axboe