[Ocfs2-tools-devel] a patch for fswreck of ocfs2-tools

Joel Becker Joel.Becker at oracle.com
Tue Aug 29 18:53:58 PDT 2006


On Wed, Aug 30, 2006 at 09:23:55AM +0800, tao.ma wrote:
> You are right. In fswreck, we need to create some special files with 
> deeper trees and with this flag we can easily do that.
> You know, if we create a file and extend it, it is quite slow to make a 
> file with deep tree.
> And since this flag is not used by other tools or lib functions, I don't 
> see any  influence to  others.

	It's part of the public interface.  We shouldn't have a
fully-generic flag in the public API for some wacky debugging scheme.
I'm going to have to NAK it.
	Now, I understand what you are trying to do.  You could try a
couple other approaches.  One would be to modify each extent_list as it
is allocated to have an l_count of 1.  That way, the regular allocation
code will consider the extent_list full after one record.  You could
basically open-code ocfs2_extend_allocation() in your application and make sure to modify l_count on any new extent_block->h_list.
	Another less interesting (from the library perspective)
possibility would be to add an internal ocfs2_insert_extent_real()
function.  This would not live in the ocfs2.h header, but in a private
header.  It would take an argument setting a flag on the struct
insert_context resulting in the behavior you want.  The
ocfs2_insert_extent() function would then call
ocfs2_insert_extent_real() with the appropriate flag unset.

Joel

-- 

Life's Little Instruction Book #157 

	"Take time to smell the roses."

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



More information about the Ocfs2-tools-devel mailing list