On Tue, Jul 29, 2014 at 05:07:31PM +0200, Torbjørn wrote: > 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.
Good news! I've reproduced it with my xfstests config, will dig into it closer. thanks, -liubo -- 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
