On Wed, 12 Sep 2007 16:49:30 +0800
"Yan Zheng" <[EMAIL PROTECTED]> wrote:
> 2007/9/12, Chris Mason <[EMAIL PROTECTED]>:
> > 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
_______________________________________________
Btrfs-devel mailing list
[email protected]
http://oss.oracle.com/mailman/listinfo/btrfs-devel
