[btrfs-devel][patch]fix for btrfs_truncate_in_trans

Chris Mason chris.mason at oracle.com
Mon Sep 17 11:17:48 PDT 2007


On Mon, 17 Sep 2007 23:31:12 +0800
"Yan Zheng" <yanzheng at 21cn.com> wrote:

> Hello
> 
> I think I find another bug in btrfs_truncate_in_trans. following code
> is copy from btrfs_truncate_in_trans. It's seem that the 'break' makes
> the function exit premature,
> In my test(create a 1M extent, then truncate it to 512K) , the
> function exits when csum item is encountered.  Remove the 'break'
> makes things even worse, when do ftruncate operation, system hangs
> immediately. I'll try to fix it tomorrow if you agree :)
> 
> if (del_item) {
> 	ret = btrfs_del_item(trans, root, path);
> 	if (ret)
> 		goto error;
> } else {
> 	break;
> }
> 

This is one of the less documented features of the truncate code, it
leaves extents there unless they are entirely contained outside new the
i_size.  This is because it assumes another snapshot may have a
reference on the extent and that it can't partially free the extent.

Technically, that's true because the current running transaction and
the old copy of the tree on disk add up to two references on the
extent.  What we need to do is split the extent up into two pieces in
the extent tree, and also change the code that frees extents to handle
the case where one file item points to two contiguous extents on disk.

So, I don't think the current code is stopping because it sees the csum
item, I think it is stopping because the 1M extent is a single extent
on disk, and when you truncate it, you don't completely remove that
extent from the file.

But, you've found a number of bugs around this, so please feel free to
disagree if you see a problem.

-chris



More information about the Btrfs-devel mailing list