From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Woodhouse Subject: Re: [PATCH 1/5] [BLOCK] Add 'discard' request handling Date: Wed, 06 Aug 2008 19:18:05 +0100 Message-ID: <1218046685.5111.124.camel@pmac.infradead.org> References: <488B7281.4020007@gmail.com> <20080726130200.f541e604.akpm@linux-foundation.org> <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> <877iauqfob.fsf@devron.myhome.or.jp> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Jens Axboe , Andrew Morton , Ric Wheeler , linux-fsdevel@vger.kernel.org, gilad@codefidence.com To: OGAWA Hirofumi Return-path: Received: from bombadil.infradead.org ([18.85.46.34]:33691 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754344AbYHFSSS (ORCPT ); Wed, 6 Aug 2008 14:18:18 -0400 In-Reply-To: <877iauqfob.fsf@devron.myhome.or.jp> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, 2008-08-07 at 01:19 +0900, OGAWA Hirofumi wrote: > David Woodhouse writes: > > > Some block devices benefit from a hint that they can forget the contents > > of certain sectors. Add basic support for this to the block core, along > > with a 'blkdev_issue_discard()' helper function which issues such > > requests. > > > > Although blkdev_issue_discard() can take an end_io function, it's > > acceptable to leave that as NULL and in that case the allocated bio will > > be automatically freed. Most of the time, it's expected that callers > > won't care about when, or even _if_, the request completes. It's only a > > hint to the device anyway. By definition, the file system doesn't _care_ > > about these sectors any more. > > Looks like good start. Thanks. Although I'm not quite sure it helps, is > there any plan to merge bios? Yes, it would be very good to merge bios. In fact, we can also allow the elevator to let discards cross reads and writes -- there's no _real_ need for them to be a soft barrier. And we can _drop_ a discard request if there's a later write to the same sectors. I was planning to do that work in the elevator later. Or preferably, leave it to someone more familiar with that code. > If fs merges contiguous blocks to one bio, bi_size will overflow. > Will we have to limit (of the device?) and separate for the device? Or just let the device deal with it in multiple requests if it needs to? I have no strong opinion. > Or how about to have #define for discard bio for BIO_RW_DISCARD users? Que? > The following seems good to convert to bio_dataless? Yes, that seems appropriate; thanks. _ -- dwmw2