From 3903257660338c41c22a2464407c8ff93c42e00b Mon Sep 17 00:00:00 2001 From: "Darrick J. Wong" Date: Mon, 9 Jan 2017 16:38:41 +0100 Subject: xfs: always succeed when deduping zero bytes commit fba3e594ef0ad911fa8f559732d588172f212d71 upstream. It turns out that btrfs and xfs had differing interpretations of what to do when the dedupe length is zero. Change xfs to follow btrfs' semantics so that the userland interface is consistent. Signed-off-by: Darrick J. Wong Reviewed-by: Dave Chinner Signed-off-by: Dave Chinner Cc: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman --- fs/xfs/xfs_reflink.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) (limited to 'fs/xfs/xfs_reflink.c') diff --git a/fs/xfs/xfs_reflink.c b/fs/xfs/xfs_reflink.c index 0edf835af32d..4d99100a4bbf 100644 --- a/fs/xfs/xfs_reflink.c +++ b/fs/xfs/xfs_reflink.c @@ -1345,8 +1345,14 @@ xfs_reflink_remap_range( goto out_unlock; } - if (len == 0) + /* Zero length dedupe exits immediately; reflink goes to EOF. */ + if (len == 0) { + if (is_dedupe) { + ret = 0; + goto out_unlock; + } len = isize - pos_in; + } /* Ensure offsets don't wrap and the input is inside i_size */ if (pos_in + len < pos_in || pos_out + len < pos_out || -- cgit v1.2.3