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). -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
