On 07/29/2014 12:18 PM, Liu Bo wrote:
On Mon, Jul 28, 2014 at 01:11:19PM +0200, Torbjørn wrote:
On 28. juli 2014 12:00, Liu Bo wrote:
<snip>
This seems to be incomplete(Looks like dmesg has reached its buffer size limit),
does /var/log/message have the whole stack info?
thanks,
-liubo
Hi,
Complete log was over 40MB. I uploaded everything from boot until
"blocked for 120 seconds" started to appear.
If you want all the trailing log as well, let me know.
https://gist.github.com/anonymous/7958d8917967f727f324
Sorry...still don't get why it's locked up, io_ctl_prepare_pages() has several
callers, and they are properly released from the code level. And the warnings
printed in the log belong to other btrfs partitions, not the hanged btrfs one,
and we're still not able to know which one holds the free space cache inode
page.
Maybe we'd better resort to a bisect between 3.14 and 3.15(I know it'd be a lot
of time though).
Here, doing rsync on compress=lzo full btrfs never hit that problem, shrug...
thanks,
-liubo
--
Torbjørn
That's too bad.
My reproducer is not 100% guaranteed to trigger the hang, so doing a
bisect might lead us to some innocent commit.
I have run the rsync + snapshot job several times here now, and no hang.
--
Torbjørn
--
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
