[Ocfs2-devel] [PATCH 13/15] ocfs2: ocfs2_group_bitmap_size has to handle old volume.
Tao Ma
tao.ma at oracle.com
Thu Apr 1 16:32:52 PDT 2010
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
>
>
>
More information about the Ocfs2-devel
mailing list