From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jens Axboe Subject: Re: [PATCH 1/5] [BLOCK] Add 'discard' request handling Date: Fri, 8 Aug 2008 13:18:29 +0200 Message-ID: <20080808111829.GP20055@kernel.dk> References: <1217900716.3454.667.camel@pmac.infradead.org> <20080805114210.GW20055@kernel.dk> <1217953741.3454.784.camel@pmac.infradead.org> <1217957140.3454.800.camel@pmac.infradead.org> <1218014703.5111.35.camel@pmac.infradead.org> <20080807184155.GE20055@kernel.dk> <1218187995.12232.95.camel@pmac.infradead.org> <20080808103041.GM20055@kernel.dk> <1218192731.12232.110.camel@pmac.infradead.org> <20080808110934.GO20055@kernel.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andrew Morton , Ric Wheeler , linux-fsdevel@vger.kernel.org, gilad@codefidence.com To: David Woodhouse Return-path: Received: from brick.kernel.dk ([87.55.233.238]:6290 "EHLO kernel.dk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757026AbYHHLSc (ORCPT ); Fri, 8 Aug 2008 07:18:32 -0400 Content-Disposition: inline In-Reply-To: <20080808110934.GO20055@kernel.dk> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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