[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