On Mon, Jan 28, 2013 at 09:52:56AM -0500, Josef Bacik wrote:
> You can run into this problem where if somebody is fsyncing and writing out
> the existing extents you will have removed the extent map from the em tree,
> but it's still valid for the current fsync so we go ahead and write it. The
> problem is we unconditionally try to merge it back into the em tree, but if
> we've removed it from the em tree that will cause problems. So fix this by
> only trying to merge it in if it is still a part of the tree. Thanks,
>
Reviewed-by: Liu Bo <bo.li.liu@xxxxxxxxxx>
> Signed-off-by: Josef Bacik <jbacik@xxxxxxxxxxxx>
> ---
> fs/btrfs/extent_map.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/fs/btrfs/extent_map.c b/fs/btrfs/extent_map.c
> index ed88f5e..9759911 100644
> --- a/fs/btrfs/extent_map.c
> +++ b/fs/btrfs/extent_map.c
> @@ -289,7 +289,8 @@ out:
> void clear_em_logging(struct extent_map_tree *tree, struct extent_map *em)
> {
> clear_bit(EXTENT_FLAG_LOGGING, &em->flags);
> - try_merge_map(tree, em);
> + if (em->in_tree)
> + try_merge_map(tree, em);
> }
>
> /**
> --
> 1.7.7.6
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
