Re: btrfs on bcache

[Chris Mason <clm@fb.com>]

On Mon, 2014-01-06 at 15:37 -0800, Kent Overstreet wrote:
> On Fri, Dec 20, 2013 at 03:46:30PM +0000, Chris Mason wrote:
> > On Fri, 2013-12-20 at 10:42 -0200, Fábio Pfeifer wrote:
> > > Hello,
> > > 
> > > I put the "WARN_ON(1);" after the printk lines (incomplete page read
> > > and incomplete page write) in extent_io.c.
> > > 
> > > here some call traces:
> > > 
> > > [   19.509497] incomplete page read in btrfs with offset 2560 and length 1536
> > > [   19.509500] ------------[ cut here ]------------
> > > [   19.509528] WARNING: CPU: 2 PID: 220 at fs/btrfs/extent_io.c:2441
> > > end_bio_extent_readpage+0x788/0xc20 [btrfs]()
> > > [   19.509530] Modules linked in: cdc_acm fuse iTCO_wdt
> > > iTCO_vendor_support snd_hda_codec_analog coretemp kvm_intel kvm raid1
> > > ext4 crc16 md_mod mbcache jbd2 microcode nvidia(PO) psmouse pcspkr
> > > evdev serio_raw i2c_i801 lpc_ich i2c_core snd_hda_intel sky2 skge
> > > i82975x_edac button asus_atk0110 snd_hda_codec snd_hwdep shpchp
> > > snd_pcm snd_page_alloc snd_timer acpi_cpufreq snd edac_core soundcore
> > > processor vboxdrv(O) sr_mod cdrom ata_generic pata_acpi hid_generic
> > > usbhid hid usb_storage sd_mod pata_marvell firewire_ohci uhci_hcd ahci
> > > ehci_pci firewire_core ata_piix libahci crc_itu_t ehci_hcd libata
> > > scsi_mod usbcore usb_common btrfs crc32c libcrc32c xor raid6_pq bcache
> > > [   19.509578] CPU: 2 PID: 220 Comm: btrfs-endio-met Tainted: P
> > > W  O 3.12.5-1-ARCH #1
> > > [   19.509580] Hardware name: System manufacturer System Product
> > > Name/P5WDG2 WS Pro, BIOS 0905    03/06/2008
> > > [   19.509581]  0000000000000009 ffff880231a63cb0 ffffffff814ee37b
> > > 0000000000000000
> > > [   19.509585]  ffff880231a63ce8 ffffffff81062bcd ffffea00085eaec0
> > > 0000000000000000
> > > [   19.509587]  ffff8802320cc9c0 0000000000000000 ffff880233b0e000
> > > ffff880231a63cf8
> > > [   19.509590] Call Trace:
> > > [   19.509596]  [<ffffffff814ee37b>] dump_stack+0x54/0x8d
> > > [   19.509601]  [<ffffffff81062bcd>] warn_slowpath_common+0x7d/0xa0
> > > [   19.509603]  [<ffffffff81062caa>] warn_slowpath_null+0x1a/0x20
> > > [   19.509614]  [<ffffffffa00b7ba8>] end_bio_extent_readpage+0x788/0xc20 [btrfs]
> > 
> > This should mean that bcache is either failing to read some blocks
> > properly or is fiddling with the bv_len/bv_offset fields.
> > 
> > Could someone from bcache comment?
> 
> Oh man, I found this and then threw up my hands in despair.
> 
> Bcache isn't doing anything with the bv_len/bv_offset fields; it may clone the
> biovec so it can retry a bio on error, if the biovecs weren't all whole pages,
> otherwise it just passes the biovec down with the next bio to the underlying
> cache/backing device.
> 
> What btrfs appears to be doing though - I couldn't believe that code actually
> _worked_, Jens please jump in here but AFAIK bv_len/bv_offset are in practice
> undefined after a bio's completed, they might have been updated if the driver
> was using blk_update_request but for many drivers that just process the entire
> bio all at once they just won't touch those fields - and that includes anything
> that clones the bio (md/dm).
> 
> This is probably relevant to immutable biovecs here...
> 
> -------------
> 
> 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.

-chris