[Ocfs2-tools-devel] [PATCH 1/2 v4] fsck: supporting fixing inode alloc group desc

piaojun piaojun at huawei.com
Thu Mar 15 06:09:04 PDT 2018


Hi Eric,

I decide to drop this patch as it seems not to be so profect. And I will
send the [PATCH 2/2] separately.

thanks,
Jun

On 2018/2/26 10:16, Eric Ren wrote:
> 
> 
> On 02/24/2018 04:40 PM, piaojun wrote:
>> Hi Eric,
>>
>> On 2018/2/23 17:55, Eric Ren wrote:
>>> Hi,
>>>
>>>>>> +    /*
>>>>>> +     * Currently we could only fix the situation that there is one gd
>>>>>> +     * in each chain, because we can hardly rebuild the gd far from
>>>>>> +     * chain header. The key problem is that we can not trust gd
>>>>>> +     * anymore as they have been corrupted. So we must relay on
>>>>>> +     * the ocfs2_chain_list struct to restore all gds.
>>>>>> +     */
>>>>> As talked in v3 as below:
>>>>>
>>>>> ===
>>>>>
>>>>>> I still think it's not proper to silently assume that there is only one gd in each chain.
>>>>>> So, could we give warning for user's attention by check how many
>>>>>> gds the allocator has?  If number of gds > the number of chain recs, give some warnings?
>>>>>> Eric
>>>>> Agree, we could give user a choice whether fixing this problem if
>>>>> gds > the number of chain recs.
>>>>>
>>>>> ===
>>>>>
>>>>> I cannot see where you enforce this?
>>>> I add some comment in log to notice user so that they can choose
>>>> whether fixing this problem.
>>>>
>>>> "Note that we could only fix the"
>>>> "situation that there is one gd in each chain",
>>> I saw it, but I mean we should check and warn users if
>>>
>>> "if gds > the number of chain recs.".
>>  From my analysis, we can hardly get the total number of gds, so I
>> notice user when corrupted gds are found.
> I'm under the impression that each chain won't have more than one gd until the record list is full,
> not sure if it's true :)
> 
> Eric
> 
>>
>> thanks,
>> Jun
> .
> 



More information about the Ocfs2-tools-devel mailing list