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. Regards YZ _______________________________________________ Btrfs-devel mailing list [email protected] http://oss.oracle.com/mailman/listinfo/btrfs-devel
