[btrfs-devel][patch]fix for btrfs_truncate_in_trans

[Yan Zheng]

2007/9/18, Chris Mason <chris.mason at oracle.com>:
> 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
>

Thanks for the clarification

Yes, I'm wrong.  But during test the non-exist bug, I have a new
discovery. It's seem there is a race between the truncate operation
and the delay allocation.  The output of 'ls -s' looks strange, when
the truncate operation is before allocation really happen.

Regards
YZ