question about ext3_find_goal with reservation

From: Mingming Cao
Date: Wed May 19 2004 - 17:06:56 EST


I just wondering, how the goal block being determined in ext3?

If we are doing sequential write, (the new logical block is next to the
last logical block), it's easy. Just increase the last physical block
recorded in i_next_alloc_goal and take that as the goal block for
ext3_new_block() to try to do allocation there.

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...)

Well I am thinking, with the ext3 reservation changes, would it make
sense that to find the goal in the reservation window, if we are doing
random write on a inode, and we have a reservation window for that
inode? In another words, when we try to find a goal for block allocation
and the write pattern is non-sequential, if the the filesystem has
reservation turned on, before we try to find a goal somewhere else,
shouldn't we try to locate the goal inside the reservation window first?

This will avoid the problem that a reservation window for an inode being
throwed away frequently when a single process open an file doing lseek
and write frequently? (We have discussed this before.)

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.

If all above make sense, then the goal should be the start block of the
reservation window. So when ext3_new_block() try to satisfy the goal
block, it will try to do allocation inside the reservation window
directly. This makes the goal outside of reservation almost impossible
in ext3_try_to_allocate_with_rsv(), unless it is doing sequential writes
and the goal is just next to the end of the reservation.

Any thoughts?

Mingming


-
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/