Re: [Ext2-devel] Re: question about ext3_find_goal with reservation

From: Mingming Cao
Date: Wed May 19 2004 - 20:07:08 EST


On Wed, 2004-05-19 at 15:52, Andrew Morton wrote:
> Mingming Cao <cmm@xxxxxxxxxx> wrote:
> > If the pattern is random write, in the current implementation(with the
> > goal fix), the ext3_find_near() will find a goal with good locality.( I
> > have a hard time understand the ext3_find_near(), need some help
> > here...)
>
> The comments in ext3_find_near() pretty well cover things.
Thanks.
>
> > With reservation, we probably don't need ext3_find_near() to guide us to
> > find a goal block. But we still need that in the case the filesystem is
> > mounted without reservation on.
>
> You might need it for the very first block allocation. For example, if the
> app opens an existing file and starts appending to it, does the current
> code correctly commence allocation immediately beyond the file's final
> block?

Good point. I will check.
>
> > If all above make sense, then the goal should be the start block of the
> > reservation window.
>
> Well. It'll be some block within the reservation window - the code should
> be recording how far across the reservation window we currently are. We
> don't want to do a linear search across the entire reservation window for
> each block allocation attempt.
Currently we don't trace the last-allocated-block-from-reservation
window, but it's doable. It's kind of duplicated with the
i_next_alloc_goal

> It would be nice to separate the old allocation things (i_alloc_block,
> i_alloc_goal, etc) from the new code completely. Making one somehow
> dependent upon or aware fo the other is confusing, and ultimately we'd like
> to remove those fields from the inode altogether.
>
yes, it's nice to do so. I will think about it.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/