[Ocfs2-tools-devel] [PATCH 1/2 v4] fsck: supporting fixing inode alloc group desc
piaojun
piaojun at huawei.com
Mon Mar 5 01:38:06 PST 2018
Hi Eric,
I got your point, and I will think about it later.
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