On Thu, Jul 24, 2014 at 10:55:47AM -0400, Chris Mason wrote: > On 07/24/2014 10:48 AM, Liu Bo wrote: > > When failing to allocate space for the whole compressed extent, we'll > > fallback to uncompressed IO, but we've forgotten to redirty the pages > > which belong to this compressed extent, and these 'clean' pages will > > simply skip 'submit' part and go to endio directly, at last we got data > > corruption as we write nothing. > > This fallback code was my #1 suspect for the hangs people have been > seeing since 3.15. I changed things around to trigger the fallback > randomly and wasn't able to trigger problems, but I was looking for > hangs and not corruptions. >
So now you're able to trigger the hang without changing the fallback code? I tried raid1 and raid0 with fsmark and rsync in different ways but still fails to reproduce the hang :-( The most weird thing is who the hell holds the free space inode's page, is it possible to share pages with other inode? (My answer is NO, but I'm not sure now...) thanks, -liubo > -chris > > -- 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
