[Ocfs2-tools-devel] [PATCH 2/3] fsck.ocfs2: Add extent list check for discontig bg.

Tao Ma tao.ma at oracle.com
Thu Jul 22 07:13:27 PDT 2010


Joel Becker wrote:
> On Thu, Jul 22, 2010 at 11:57:28AM +0800, Tao Ma wrote:
>   
>> On 07/22/2010 11:17 AM, Joel Becker wrote:
>>     
>>> 	Are you thinking that if e_leaf_clusters>cpg, we know it's
>>> corrupted, but if it's just big enough to add up to greater than cpg, we
>>> have no idea what happened?
>>>       
>> yeah, so I think in both case, we need to drop the group because:
>> in the 1st case, sure it is corrupted.
>> in the 2nd case, what if the 1st extent rec's e_leaf_clusters is
>> corrupted and trigger the final number to be greater than cpg or it
>> is really a rare case for us to have a corrupted extent record
>> before the last one?
>>     
>
> 	Good point.  Ok, in both cases we drop the group.
>
>   
>> That makes me now think that can we really fix a e_leaf_clusters
>> error based on the sum of other *looked sane* extent records?
>>     
>
> 	Yes, I think we can.  If you have multiple places corrupt, you
> likely have someone scribbling over things with dd(1) or something.
> It will tend to be really corrupt.  But if you have exactly one thing
> corrupt, you probably have a code error or some other corruption that
> just twiddled a bit or a byte.
> 	So when we see e_leaf_clusters is completely impossible, we know
> that particular record got corrupted.  If everything else looks perfect,
> it's very likely a single corruption.  That's why I think we can fix it.
> 	When e_leaf_clusters is possible but just adds up to more than
> cpg, we don't know which e_leaf_clusters was corrupted, including
> possibly more than one.  So we can't fix it.
>   
OK, so I will change it accordingly.

Regards,
Tao



More information about the Ocfs2-tools-devel mailing list