[Ocfs2-tools-devel] [PATCH 10/20] bitmap: Add 2 fields to facilitate discontiguous block group.

[Tao Ma]

Joel Becker wrote:
> On Fri, Jun 11, 2010 at 07:57:54AM +0800, Tao Ma wrote:
>   
>> Joel Becker wrote:
>>     
>>> 	Why are you creating multiple regions?  A region is a bitmap
>>> hunk, not a disk hunk.  So you could just have one region with the
>>> entire gd bitmap, but when you go to use it you could have specific
>>> get/set functions that know how to read the right blkno.
>>>   
>>>       
>> I was thinking of this, but have to give up finally. It is not easy to 
>> integrate to our
>> bitmap region code. ;)
>> Say one gd has the following extent rec list [1000, 10], 
>> [1100,10],[1200,10]...[2900,10].
>> If we unit it to be a bitmap region we will have a [1000,200].
>> But if we have a chance to have another gd has the following rec list 
>> [1150,10]...
>> we will have a [1150, 200]. This will collide with the original one. 
>> Current bitmap region
>> code can't handle this by now.
>>     
>
> 	How will it collide?  The 1000 is the address of the group
> descriptor, and 200 is the number of blocks it describes.  It doesn't
> have to be a physical count.
> 	What portion of the code hits this as a physical overlap?
>   
We use ocfs2_bitmap to indicate the whole bitmap region and rb-tree is 
used here.
So for the first [1000, 200], we call ocfs2_bitmap_insert_region to 
insert a rb-node
which have [1000,200]. So for the 2nd group ocfs2_bitmap_insert_region 
will call
ocfs2_bitmap_lookup to find one. And look at this line:

 /* we shouldn't find an existing region that intersects our new one */
        br_tmp = ocfs2_bitmap_lookup(bitmap, br->br_start_bit,
                                     br->br_total_bits, &p, &parent, NULL);
        if (br_tmp)
                return OCFS2_ET_INVALID_BIT;

This is what I get just now. I can't recalled the problem when I 
implement it. But there
should be some other things that let me finally give it up.

Regards,
Tao