On Mon, Mar 13, 2017 at 10:58:29PM +0100, Kai Krakow wrote: > Am Sat, 28 Jan 2017 15:50:38 -0500 > schrieb Matt McKinnon <matt@xxxxxxxxxxxxxx>: > > > This same file system (which crashed again with the same errors) is > > also giving this output during a metadata or data balance: > > This looks somewhat familiar to the err=-17 that I am experiencing when > using VirtualBox image on btrfs in CoW mode (compress=lzo). > > During IO intensive workloads, it results in "object already exists, > err -17" (or similar, someone else also experienced it through another > workload). The resulting btrfs check show the same errors, giving > inodes without csum. > > Trying to continue using this file system in successive boots usually > results in boot freezes or complete unmountable filesystem, broken > beyond repair. > > I'm feeling that using the bfq elevator usually enables me to trigger > this bug also without using VirtualBox, i.e. during normal system > usage, and mostly during boot when IO load is very high. So I also > stopped using bfq although it was giving me a much superior > interactivity. > > Marking vbox images nocow and using standard elevators (cfq, deadline) > exposes no such problems so far - even during excessive IO loads. > > EOM This sounds similar to a bug I fixed here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8e2bd3b7fac91b79a6115fd1511ca20b2a09696d That change is in v4.10. If you're not already running a kernel version with that fix, could you check if that solves it? -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
