On Thu, Sep 17, 2009 at 01:39:01PM -0500, Steven Pratt wrote: > Eric Whitney wrote: > > > > > >Chris Mason wrote: > >>On Mon, Sep 14, 2009 at 04:41:48PM -0500, Steven Pratt wrote: > >>>Only bit of bad news is I did get one error that crashed the system > >>>on single threaded nocow run. So that data point is missing. > >>>Output below: > >> > >>I hope I've got this fixed. If you pull from the master branch of > >>btrfs-unstable there are fixes for async thread races. The single > >>patch I sent before is included, but not enough. > > > >Chris: > > > >FYI - all five of my test systems have now finished my standard > >test cycle on the -unstable master branch, and I've not seen a > >single hang. So, your fix for the async thread shutdown race seems > >to have fixed my problems, even if Steve's still seeing trouble. > > > >I'll note that the running times for fsstress on some of my > >systems have become rather longer with btrfs-unstable/master > >kernels - 3.5 rather than 2.5 hours on multidevice filesystems. > >Running times on single device filesystems are roughly the same. > > > >I'm going to start another set of tests for thoroughness unless > >you've got more patches coming. > I've had some offline discussions with Chris, and it seems the > problem is triggered by unmounting and re-mounting the file system > between tests (but not running mkfs again). I have also just > verified that the problem does not occur if repeated tests are run > without the unmount mount cycle. So in case this is not clear:
Ok, I've triggered it here. Next step is trying Yan Zheng's async caching update. ------------[ cut here ]------------ kernel BUG at fs/btrfs/extent-tree.c:4097! invalid opcode: 0000 [#1] SMP -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
