Re: [PULL] Btrfs for 4.7, part 2

[Chris Mason <clm@fb.com>]

On Fri, May 27, 2016 at 10:35:27AM -0400, Chris Mason wrote:
> On Fri, May 27, 2016 at 01:18:22PM +0200, David Sterba wrote:
> > On Thu, May 26, 2016 at 08:14:14PM -0400, Chris Mason wrote:
> > > On Thu, May 26, 2016 at 11:27:06AM +0200, David Sterba wrote:
> > > > Hi,
> > > > 
> > > > please pull a few more patches that did not go to pull #1 for 4.7, minor
> > > > cleanups and fixes. Thanks.
> > > 
> > > Thanks Dave!  Trying to figure out why we're failing btrfs/011, but I
> > > don't see how it could be related to this bunch.  I'll nail it down.
> > 
> > 011 passes here, there are some unrelated soft-failures (mismatching
> > output with new progs). I'm now testing a branch without "btrfs: scrub:
> > Set bbio to NULL before calling btrfs_map_block", that seems to be the
> > only likely offender.
> 
> I'm getting errors from btrfs fi show -d, after the very last round of
> device replaces.  A little extra debugging:
> 
> bytenr mismatch, want=4332716032, have=0
> ERROR: cannot read chunk root
> ERROR reading /dev/vdh
> failed /dev/vdh
> 
> Which is cute because the very next command we run fscks /dev/vdh and
> succeeds.
> 
> So the page cache is stale and this isn't related to any of our patches.

close_ctree() calls into btrfs_close_devices(), which calls
btrfs_close_one_device(), which uses:

call_rcu(&device->rcu, free_device);

close_ctree() also does an rcu_barrier() to make sure and wait for
free_device() to finish.

But, free_device() just puts the work into schedule_work(), so we don't
know for sure the blkdev_put is done when we exit.

It's been this way for a while, so its not holding up my pull request to
Linus.  But I'll fix it up.

-chris