[Ocfs2-tools-devel] [PATCH 2/2] looped chain - Break loop in fsck

tristan tristan.ye at oracle.com
Thu Mar 4 18:47:51 PST 2010


Sunil Mushran wrote:
> tristan wrote:
>> Sunil Mushran wrote:
>>> Let me also add my 2 cents worth.
>>>
>>> For the global bitmap, why don't we compute the list of expected values
>>> and check against that. That will be a lot more precise. This check can
>>> be added in CHAIN_LINK_RANGE.
>>
>> Sorry, here I didn't quite understand your suggestion well, are we 
>> going to validate the starting blkno of each cluster group in 
>> CHAIN_LINK_RANGE? then correct them by our calculation if any 
>> mismatch happened? if it's the case, it looks like s a strengthening 
>> to CHAIN_LINK_RANGE?  may that need a new prompt code in this case?
>>
>> Or we're going to take this into account in CHAIN_LOOP case? that 
>> means, we can break the loop by pointing to a correct blkno we 
>> calculated, instead of  terminating it as NULL.
>>
>> Could you please explain more about the motivation?
>
> I am talking about only the global bitmap. The one attribute
> the our cluster bitmap has that the blocknumbers in each chain
> group can be computed. We won't know the order. But we know
> the list of values to expect. The order is unknown because we keep
> reordering it.

Got:)

>
> So instead of looking for only a loop, we can cast a wider net by
> also ensuring the value is one of expected.

Since we have no idea about the order, the value will be validated to 
see if it is within our calculated list, then how we fix this if it's 
not the case, how to redirect the blkno? which blkno will be the 'next':)?

>
> Having said that, the reality is that the loop will probably be our
> biggest problem.
>
> This is just a thought. Joel thinks we should be already doing that
> check. If so, then ignore my mutterings.
>
> BTW, maybe more in line if it is called CHAIN_LINK_LOOP.
>
> Sunil




More information about the Ocfs2-tools-devel mailing list