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

Tao Ma tao.ma at oracle.com
Wed Mar 31 21:50:56 PDT 2010


Tao Ma wrote:
> Hi wengang,
> 
> Wengang Wang wrote:
>> On 10-04-01 12:22, Tao Ma wrote:
>>> Hi Joel,
>>>
>>> Joel Becker wrote:
>>>> On Thu, Apr 01, 2010 at 10:59:10AM +0800, Tao Ma wrote:
>>>>> ocfs2_group_bitmap_size has to handle the case when the
>>>>> volume don't have discontiguous block group support.
>>>> 	NAK.  We specify 256 in all cases.  This doesn't hurt old code
>>>> because we've never used more bits.  Even though our old bg_size values
>>>> were much larger, we never used that space because bg_bits was set to
>>>> the smaller value.
>>> No, it hurts.
>> Hi, 
>>> So with an old ocfs2-tools and a new kernel, the new kernel will set it 
>>> to 256 while the old ocfs2-tools refused to work by checking bg_size(see
>>> chainalloc_process_group in libocfs2).
>> Just for my info.
>> Is "old ocfs2-tools + new kernel" supported?
> I guess yes? I am not sure whether a user can use a 2.6.35 kernel(the 
> next merge window) while using an ocfs2-tools 1.4.
actually the most worse thing I am worried about it that: the old 
fsck.ocfs2 refused to fsck the volume even in case we don't enable 
discontig-bg because the new kernel set bg_size=256 so the new inode 
group will be considered corrupted. I don't think it is endurable for a 
user.

Regards,
Tao



More information about the Ocfs2-devel mailing list