Btrfs devel - Aug 2011 - clone ioctl bug with inline extents

Hi all,

I''m hitting a problem cloning inline extents that I haven''t
had much
success tracking down.  It''s simple enough to reproduce:

 echo 1111111111111111111111111111 > src
 echo 2 > dst
 clone_range src 0 29 dst 0
 cmp src dst       # fails! dst is size 29 but contains
"2\n\0\0\0\0..."

where clone_range comes from 

 http://ceph.newdream.net/git/?p=ceph.git;a=blob;f=qa/btrfs/clone_range.c;h=0a88e16013104c27aa87e7cd0d75e4d292419a19;hb=HEAD

The file size is adjusted for the target, and debug-tree shows an inline 
data extent of length 29, but it has the old data in it.  I''m not sure
why

				ret = btrfs_insert_empty_item(trans, root, path,
							      &new_key, size);
				BUG_ON(ret);

				[...]

				leaf = path->nodes[0];
				slot = path->slots[0];
				write_extent_buffer(leaf, buf,
					    btrfs_item_ptr_offset(leaf, slot),
					    size);
				inode_add_bytes(inode, datal);

is working when cloning to a new file but not over an existing one.  
Hopefully this is something silly I''m missing...

sage
--
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

On Tue, 9 Aug 2011, Sage Weil wrote:
> Hi all,
> 
> I''m hitting a problem cloning inline extents that I
haven''t had much
> success tracking down.  It''s simple enough to reproduce:
> 
>  echo 1111111111111111111111111111 > src
>  echo 2 > dst
>  clone_range src 0 29 dst 0
>  cmp src dst       # fails! dst is size 29 but contains
"2\n\0\0\0\0..."
<facepalm>, ok, this was just a matter of the ioctl code not dropping the 
old page cache pages.  I''m not sure how we didn''t notice that
for so long!

sage
--
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