[btrfs-devel][patch]Cache blocks in the hole at beginning of a block group

[Chris Mason]

On Wed, 12 Sep 2007 16:49:30 +0800
"Yan Zheng" <yanzheng at 21cn.com> wrote:

> 2007/9/12, Chris Mason <chris.mason at oracle.com>:
> > Thanks, you've definitely found a bug in the current code, but I'm
> > afraid we can't assume the start of the block group is free.  There
> > could be an extent allocated in the last block group that extends
> > into the current one.
> >
> 
> Thanks for comment.
> 
> I feel if there are extent items across block group boundary,  we also
> can't guarantee start of the block group is free in other tests (in
> cache_block_group) . In addition, the subtraction operation in codes
> like:
> --------------------------------------------------------
> if (found) {
>     hole_size = block_group->key.objectid +
>                          block_group->key.offset - last;
> }
> -------------------------------------------------------
> may overflow. The overflow bug can  easily produce by adding a extent
> item across boundary of block group 0 and block group 1.
> 
> 
> here is the new patch . it finds the start of free block in a block
> group by checking the first extent item (the one found by
> btrfs_search_slot directly, it should belong to preceding block group
> except for the first block group).  it also add check for overflow.

Thanks, this looks better.  I'll give it a try here.

-chris