Comment # 5 on bug 1047793 from Aleksa Sarai

> I tried the crash_btrfs.c, and it lead to the same behavior I was seeing
> with the docker stop command, so it appears that it is the same issue. I've
> had to rollback using an older snapshot on several occasions, and I know
> that it mounts the snapshot ro first and then after the rollback it mounts
> the snapshot as rw. Is the fact that I've rolled back what is causing me to
> experience this issue and not others? This seems like a pretty big bug...

No, I don't believe this is the case -- I've never done rollbacks on my
machines. Docker has to trigger btrfs rescans all the time as part of how the
btrfs storage driver is implemented. If you shut down your system in the middle
of a rescan, btrfs will set a flag so it will resume the rescan when it gets
mounted again. However, it will only do the rescan on rw mounts, and the bug in
btrfs is that remounting a ro filesystem as rw (which is something that it
appears initrd does on boot for every openSUSE install) doesn't trigger the
rescan.

So when you then try to do an operation that wants to wait for any pending
rescans to finish, it soft locks because the rescan job isn't running (but it
thinks it is).

My patch fixes the last part of that so that it will get retriggered when you
do a rw remount.

> I didn't follow your explanation for how I might potentially fix the
> qgroup-rescan-running flag issue. Is there a script that I could run that
> would reset the flag? I could switch storage drivers as well, but my use
> case for docker isn't super urgent, so I may just wait for it to be fixed in
> the kernel.

Boot into a livecd, then manually mount your root partition as read-write.
Something like

% sudo mount -t btrfs -o rw /dev/sdXY /mnt

*should* cause the rescan to trigger. The other option is to compile your own
kernel with my patch and boot into it. I expect that the patch will get
reviewed soon though (this week was July 4th, so everyone is coincidentally on
vacation).