On Wed, Feb 5, 2014 at 4:20 PM, Josef Bacik <jba...@fb.com> wrote: > > On 02/05/2014 11:14 AM, Wang Shilong wrote: >> >> Hi Filipe, >> >>> So i knew what was wrong here, we need found_key while >>> btrfs_previous_extent_item() did set >>> it properly..^_^ >>> >>> I will send a v2 to fix this, thanks! >>> >>> >>>> On Fri, Jan 31, 2014 at 4:42 PM, Wang Shilong >>>> <wangshilong1...@gmail.com> wrote: >>>>> >>>>> From: Wang Shilong <wangsl.f...@cn.fujitsu.com> >>>>> >>>>> Since we have introduced btrfs_previous_extent_item() to search >>>>> previous >>>>> extent item, just switch into it. >>>>> >>>>> Signed-off-by: Wang Shilong <wangsl.f...@cn.fujitsu.com> >>>> >>>> Hi Shilong, >>>> >>>> This patch is making btrfs/004 fail for me, consistently: >> >> I was trying to reproduce this xfstest failure(though we have known what's >> wrong with my previous patch). >> I did not really hit 004 failure, but i can reproduce btrfs/030 fail >> consistently, i think you might be interested in this: >> > Do you guys have some CONFIG_ONLY_BREAK_FOR_ME=y set or something? I can't > reproduce this failure either. Will you send the updated > btrfs_previous_extent_item patch and then see if you can bisect down why 030 > is failing for you? Thanks,
I can't reproduce Shilong's 030 failure on latest btrfs-next, neither with nor without the previous_extent_item patch. And quite surprised, since the test is very deterministic (hardcoded fs structure). > > Josef -- Filipe David Manana, "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." -- 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
