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