[btrfs-devel][patch]fix for btrfs_truncate_in_trans

Chris Mason chris.mason at oracle.com
Tue Sep 18 07:13:13 PDT 2007


On Tue, 18 Sep 2007 15:59:32 +0200
Christoph Hellwig <hch at lst.de> 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






More information about the Btrfs-devel mailing list