On Tue, Sep 20, 2016 at 04:51:21PM -0400, Sean Greenslade wrote: > On Tue, Sep 20, 2016 at 01:02:38PM +0800, Qu Wenruo wrote: > > > Glad to hear you've found the core of the issue. > > > > > > At this point, I can trigger it immediately. As soon as I log in and run > > > dmenu, it will attempt to rebuild its cache file (small text file that's > > > just a list of all executables in the PATH). Once that write happens, > > > the bug triggers and the fs goes read only. > > > > Rewrite? Or write into new inode? > > > > And is the same inode always causing the problem? > > It's not always the same. It seems like whatever triggers a write first > is what kills it. I went to test it, and this time it triggered on my > .bash_history file. I have bash set up with "history -a", so presumably > that was an append, not an overwrite. > > To cut down on the number of variables, I booted my system with the > "rescue" systemd target, then su'd to my user. Simply running a few > commands (with the history -a writes that bash triggered) was enough to > trigger the bug. This is on 4.8.0-rc6, with the following compile time > options enabled: > > CONFIG_BTRFS_FS_RUN_SANITY_TESTS=y > CONFIG_BTRFS_DEBUG=y > CONFIG_BTRFS_ASSERT=y > > If I run the stock Arch kernel (4.7.2 at the moment), the issue still > appears, but it takes longer. My most reliable trigger is Firefox, whose > constant DB writes will trigger it within minutes.
Is there anything I can do to help this along? I can build experimental patches, set up long running scripts, run tests, whatever is necessary. Thanks, --Sean -- 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
