From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kent Overstreet Subject: Re: btrfs on bcache Date: Wed, 8 Jan 2014 13:13:07 -0800 Message-ID: <20140108211307.GB7291@kmo-pixel> References: <1387483201.23881.2.camel@ret.masoncoding.com> <1387554401.9407.0.camel@ret.masoncoding.com> <20140106233704.GI9037@kmo> <1389209759.23310.27.camel@ret.masoncoding.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mail-pb0-f43.google.com ([209.85.160.43]:38376 "EHLO mail-pb0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757419AbaAHVLv (ORCPT ); Wed, 8 Jan 2014 16:11:51 -0500 Received: by mail-pb0-f43.google.com with SMTP id rq2so2067299pbb.30 for ; Wed, 08 Jan 2014 13:11:51 -0800 (PST) Content-Disposition: inline In-Reply-To: <1389209759.23310.27.camel@ret.masoncoding.com> Sender: linux-bcache-owner@vger.kernel.org List-Id: linux-bcache@vger.kernel.org To: Chris Mason Cc: "linux-btrfs@vger.kernel.org" , "eab@gmx.ch" , "linux-bcache@vger.kernel.org" , "fmpfeifer@gmail.com" , "axboe@kernel.dk" On Wed, Jan 08, 2014 at 07:35:32PM +0000, Chris Mason wrote: > On Mon, 2014-01-06 at 15:37 -0800, Kent Overstreet wrote: > > Ok, I looked again at the relevant btrfs code, I guess I can see how this printk > > isn't normally triggered. But Chris, _what on earth_ is btrfs trying to check > > for here? And why is it using bv_offset and bv_len further down in > > end_bio_extent_readpage()? > > After the IO is done, we're recording the specific logical byte range > that covered the IO. In practice its always the full page, we can > switch to just trusting PAGE_CACHE_SIZE. Yeah, the code already assumes it was doing PAGE_CACHE_SIZE reads; what you're effectively checking is that the driver did the bvec all at once, and that it didn't process half a bvec, update it, then process the rest - which is a completely fine thing to do. So for now - yeah, the correct thing to do is to just ignore bv_offset/bv_len and go by PAGE_CACHE_SIZE. But - after immutable biovecs is in, _then_ you'll be able to depend on bv_offset/bv_len remaining unchanged (and you can get rid of your dependency on PAGE_CACHE_SIZE bvecs).