[Ocfs2-tools-devel] [PATCH 5/6] Resend: Add unwritten extent support in ocfs2-tools, take 2

[Joel Becker]

On Thu, Sep 27, 2007 at 08:37:25AM +0800, tao.ma wrote:
> For ocfs2_extent_iterate, we just gave the extent record to the user. so 
> the user's callback should handle it. So there is no need for modify the 
> iteration process. Maybe I need to check all the caller to check whether 
> their callbacks handle this.

	That's the first step.  I was thinking something along the lines
of EXTENT_CHANGED, perhaps EXTENT_DATA_CHANGED, where the iterate code
would say "Oh, I'd better mark this written".  But I don't think we want
to go there just yet.

> In ocfs2_block_iterate, we just iterate all the extent records and give the 
> block num to the user's callback.  As for unwritten extent record, do you 
> think we should add a new parameter in the callback's definition that this 
> block exist in a unwritten extents? I am not quite sure of it.

	Oho!  We have a problem.  In ocfs2_read_whole_file, we have a
reader function (read_whole_func) that doesn't check unwritten extents.
That needs to be added to patch #6.  Of course, how to tell the
function?
	Also, extras/set_random_bits.c uses it.  I think that the
fsck.ocfs2 users are safe (symlinks and directories).

Joel

-- 

"Every day I get up and look through the Forbes list of the richest
 people in America. If I'm not there, I go to work."
        - Robert Orben

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