clone ioctl bug with inline extents

[Sage Weil]

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   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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: clone ioctl bug with inline extents

[Sage Weil]

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   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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html