[Ocfs2-devel] Re: [Ocfs2-tools-devel] [PATCH 5/6] Modify fsck to trust global bitmap than super block.take 3

[tao.ma]

Sunil Mushran wrote:
> I still need to go thru the fs code for resize. But under what
> condition will the global bitmap be updated and not the
> superblock?
Actually in kernel, we update the global_bitmap first and then the super 
block and backups.
And if the super block and backups' update fail, the kernel doesn't care 
about it  and only output some in message since the kernel only use the 
info stored in global_bitmap.
>
> My problem with the fsck change is that we are manipulating
> fs->fs_clusters directly. This will just cause us grief later.
> It is best if this is populated only in ocfs2_open().
If we populate in ocfs2_open, maybe we need another flag and check 
global_bitmap if needed?
>
> Sunil
>
> tao.ma wrote:
>> Sunil Mushran wrote:
>>> Tao Ma wrote:
>>>> In resize, we update the global_bitmap first and then the super block.
>>>> So if there is any corruption between these 2 steps, there will be a
>>>> inconsistence. In kernel we use the information in global_bitmap,
>>>> so fsck.ocfs2 should also trust it during the check.
>>>>
>>>> Signed-off-by: Tao Ma <tao.ma at oracle.com>
>>>> ---
>>>>   
>>> Signed-off-by: Sunil Mushran <sunil.mushran at oracle.com>
>>>
>>> This looks correct. However, I am still confused as to how I managed to
>>> get clean runs when testing aborted offline resize cases.
>> In your offline resize design, you write this:
>>
>>    * Segfault after writing global bitmap but before the superblock.
>>
>> /fsck will remove all the new BGs that are beyond the end-of-volume 
>> as determined by the superblock->num_clusters.
>>
>>
>> So we trust superblock rather than global_bitmap and it works as the 
>> design expects when testing aborted offline resize cases.
>> Now the order is reversed, so I think maybe I need to revise your 
>> design doc so that it doesn't lead to the "strange" result.
>> Agree?
>> /
>