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