On Fri, Jan 05, 2018 at 12:51:07PM -0700, Liu Bo wrote:
> Although
> commit e6c4efd87ab0 ("btrfs: Fix and enhance merge_extent_mapping() to insert 
> best fitted extent map")
> fixed up the negetive em->len, it has introduced several regressions, several 
> has been fixed by
> 
> commit 32be3a1ac6d0 ("btrfs: Fix the wrong condition judgment about subset 
> extent map"),
> commit 8dff9c853410 ("Btrfs: deal with duplciates during extent_map insertion 
> in btrfs_get_extent") and
> commit 8e2bd3b7fac9 ("Btrfs: deal with existing encompassing extent map in 
> btrfs_get_extent()").
> 
> Unfortunately, there is one more regression which is caught recently by a
> user's workloads.
> 
> While debugging the above issue, I found that all of these bugs are caused
> by some racy situations, which can be very tricky to reproduce, so I
> created several extent map specific test cases in btrfs's selftest
> framework.
> 
> Patch 1-2 are fixing two bugs.
> Patch 3-4 are some preparatory work.
> Patch 3-5 are regression tests about the logic of handling EEXIST from
> adding extent map.
> Patch 8-10 are debugging wise, one is a direct tracepoint and the other is
> to enable kprobe on merge_extent_mapping.
> 
> v2:
> - Improve commit log to provide more details about the bug.
> - Adjust bugfixes to the front so that we can merge them firstly.

Patchset updated in for-next. Expected merge target is 4.16, review is
still needed (and welcome).
--
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

Reply via email to