On Mon, Jan 23, 2017 at 02:55:21PM -0700, Chris Murphy wrote: > On Mon, Jan 23, 2017 at 2:50 PM, Chris Murphy > > I haven't found the commit for that patch, so maybe it's something > > with the combination of that patch and the previous commit. > > I think that's provably not the case based on the bisect log, because > I hit the problem with kernel that has only the commit, as well as the > commit plus the updated patch. So the patch neither causes nor fixes > the problem I'm experiencing. > > If it's useful the btrfs-image is here; mentioned in a previous > thread, this image mounts find, btrfs check --mode=original has no > complaints, but btrfs check --mode=lowmem has complaints. There's no > problem using the parent subvolume as rootfs. Only snapshots of that > subvolume result in the problem. > https://drive.google.com/open?id=0B_2Asp8DGjJ9ZmNxdEw1RDBPcTA
What I meant to ask was if there were false positives/false negatives in booting from the subvolume that would lead you to doubt the results of the git bisect, but it sounds like it's 100% reproducible for you? I'll take a look at the image. In the meantime, could you try booting with https://gist.github.com/osandov/9f223bda27f3e1cd1ab9c1bd634c51a4 applied on top of 4.9 so we can hopefully narrow it down? It'd also be great to know if it always fails the same way or if it varies. -- 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
