[Ocfs2-devel] [PATCH 13/15] ocfs2: ocfs2_group_bitmap_size has to handle old volume.

[Tao Ma <tao.ma@oracle.com>]

Joel Becker wrote:
> On Thu, Apr 01, 2010 at 03:46:43PM +0800, Tao Ma wrote:
>   
>> Joel Becker wrote:
>>     
>>> 	So we do need the kernel to store the old-style bg_size in order
>>> to keep compatibility.  But we can do better.  First, you don't need the
>>> supports_discontig_bg argument.  You already have the superblock, just
>>> check ocfs2_supports_discontig_bg(OCFS2_SB(sb)).
>>>       
>> I have thought of this before, but finally I gave up. The reason is
>> that OCFS2_SB(sb) use ocfs2_super which is declared in ocfs2.h. So
>> you see, I don't want to overlap these 2 head files.
>>     
>
> 	You're right about OCFS2_SB().  This comes back to your
> userspace version of the interface too, where we don't even have the
> superblock.
> 	Perhaps the ocfs2_fs.h version of the function needs the awful
> integer arguments.  Maybe we can define a wrapper interface in ocfs2.h
> that takes the smarter arguments.  This would allow most call sites to
> read better.
> 	We could also define it as ocfs2_group_bitmap_size(struct
> super_block *sb, int sysfile_type, u32 feature_incompat).  This requires
> we pass in arguments that are obvious on their face.  We're going to
> have to know the information when we call the function anyway.
>   
I just went through all the callers of ocfs2_group_bitmap_size and it 
seems that it is called in 2 scenarios:
1. set bg_size.
2. check some situation in resize.

So how about change it to
ocfs2_group_bitmap_size(struct super_block *sb, struct ocfs2_group_desc *gd)
so if gd is NULL, we returns the old value, if not, just return bg_size.

As for place of setting bg_size, we can set bg_bits first and then set 
bg_size to (bg_bits +7)/8.

Regards,
Tao
> Joel
>
>
>