On Tue, 18 Sep 2007 17:45:00 +0800 "Yan Zheng" <[EMAIL PROTECTED]> wrote:
> 2007/9/18, Chris Mason <[EMAIL PROTECTED]>: > > 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 _______________________________________________ Btrfs-devel mailing list [email protected] http://oss.oracle.com/mailman/listinfo/btrfs-devel
