[btrfs-devel][patch]fix for btrfs_truncate_in_trans

[Chris Mason]

On Tue, 18 Sep 2007 17:45:00 +0800
"Yan Zheng" <yanzheng at 21cn.com> wrote:

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

Odd, the i_blocks changes happen inside file_write, not at delalloc
time.  Could you please try to narrow the problem down?

-chris