On Tue, 18 Sep 2007 15:59:32 +0200 Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 18, 2007 at 09:47:09AM -0400, Chris Mason wrote: > > > 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. > > I still haven't gotten truncate to work, but as far as i_block is > concerend I couldn't care less. The only place i_blocks is acutally > used is generic_fillattr which XFS doesn't use. XFS does it's > internal space used accounting and we just copy that directly in > struct kstat. Ok, btrfs_drop_extent_cache is the easy place to do it. I would change it like this: int btrfs_drop_extent_cache(struct inode *inode, u64 start, u64 end, u64 *delalloc_bytes) And have it return the number of byts it found in the extent mapping tree where the block_start was EXTENT_MAP_DELALLOC. Then btrfs_truncate_in_trans can properly decrement i_blocks after calling btrfs_drop_extent_cache. try_release_extent_mapping should also be changed not to drop things from the extent mapping tree if they are EXTENT_MAP_DELALLOC. Just let me know if this doesn't make sense ;) -chris _______________________________________________ Btrfs-devel mailing list [email protected] http://oss.oracle.com/mailman/listinfo/btrfs-devel
