[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