[Ocfs2-tools-devel] [PATCH 17/20] fsck.ocfs2: Make pass0 aware of discontig block group.

[Joel Becker]

On Sat, Jul 17, 2010 at 10:40:51PM +0800, Tao Ma wrote:
> yes, I knew that and actually my discontiguous block group will also
> be set in the
> global bitmap in mark_group_used.

	Yes, which is great.  I just worried if l_next_free_rec was
bogus, we might walk of the end or something.  That can't happen with a
contig bg because we just count cpg from an already validated bg_blkno.

> So let me describe what I think we need for discontiguous block group check:
> 1. do some sanity check for the extent list. includes
> l_tree_depth(should always be 0),
>   l_count and l_next_free_rec.
> 2. for each extent_record, check whether we have a valid e_cpos.
> 3. for the whole extent list, check whether the total clusters number = cpg.
> If there is any error during the check, just remove the whole group.

	I think this sounds pretty reasonable.  If an extent has a bad
e_cpos, we can't really fix that.  However, I think that l_tree_depth
can be fixed to 0, l_count can be fixed to extent_recs_per_gd and
l_next_free_rec can even be fixed in the trivial case.
	How would one figure l_next_free_rec?  Well, if you walk the
extents and discover that N extents add up to exactly cpg, doesn't that
have to be the l_next_free_rec?  If you run into a zero extent before
counting cpg, the whole group has to be removed, of course.
	What about fixing a bad e_leaf_clusters?  I don't think we can
handle all the possible combinations, but if we find an e_leaf_clusters
that would clearly go past the cpg, I think we can check the remaining
extents and see via subtraction what it should have been.

Joel

-- 

"I am working for the time when unqualified blacks, browns, and
 women join the unqualified men in running our overnment."
	- Sissy Farenthold

Joel Becker
Consulting Software Developer
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127