Message ID | 20180105195117.5131-2-bo.li.liu@oracle.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On Fri, Jan 05, 2018 at 12:51:08PM -0700, Liu Bo wrote: > %block_len could be checked on deciding if two em are mergeable. > > merge_extent_mapping() has only added the front pad if the front part > of em gets truncated, but it's possible that the end part gets > truncated. > > For both compressed extent and inline extent, em->block_len is not > adjusted accordingly, and for regular extent, em->block_len always > equals to em->len, hence this sets em->block_len with em->len. > > Signed-off-by: Liu Bo <bo.li.liu@oracle.com> Reviewed-by: Josef Bacik <jbacik@fb.com> Thanks, Josef -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index e1a7f3c..2784bb3 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -6860,7 +6860,7 @@ static int merge_extent_mapping(struct extent_map_tree *em_tree, if (em->block_start < EXTENT_MAP_LAST_BYTE && !test_bit(EXTENT_FLAG_COMPRESSED, &em->flags)) { em->block_start += start_diff; - em->block_len -= start_diff; + em->block_len = em->len; } return add_extent_mapping(em_tree, em, 0); }
%block_len could be checked on deciding if two em are mergeable. merge_extent_mapping() has only added the front pad if the front part of em gets truncated, but it's possible that the end part gets truncated. For both compressed extent and inline extent, em->block_len is not adjusted accordingly, and for regular extent, em->block_len always equals to em->len, hence this sets em->block_len with em->len. Signed-off-by: Liu Bo <bo.li.liu@oracle.com> --- fs/btrfs/inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)