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-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
