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 -- 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
