On Tue, 18 Sep 2007 21:31:54 +0800 "Yan Zheng" <[EMAIL PROTECTED]> wrote:
> 2007/9/18, Chris Mason <[EMAIL PROTECTED]>: > > > > > > 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 > > > When allocation doesn't really happen, there is no extent item. So > btrfs_truncate_in_trans finds nothing and i_blocks isn't updated. Ok, that makes sense. Christoph, what fits best in with your delalloc plans for XFS? Should extent_invalidatepage return some information about the number of delalloc bytes it found so that btrfs_invalidatepage can drop i_blocks? At the start of btrfs_truncate, we call btrfs_drop_extent_cache. That could also send back information on the number of delalloc extent maps that were found. -chris _______________________________________________ Btrfs-devel mailing list [email protected] http://oss.oracle.com/mailman/listinfo/btrfs-devel
