Re: [PATCH 0/4] ext3 block reservation patch set

[Badari Pulavarty <pbadari@us.ibm.com>]

On Wednesday 14 April 2004 04:02 pm, Andrew Morton wrote:


> > In our TODO list. But our original thought was, we have to search only
> > the current block group reservations to get a window. So, if we have lots
> > & lots of reservations in a single block group - search gets complicated.
> > We were thinking of adding (dummy) anchors in the list to represent
> > begining of each block group, so that we can get to the start of a block
> > group quickly. But so far, we haven't done anything.
>
> hm, I need to look at the new code more closely.  I was hoping that we
> could divorce the reservation windows from any knowledge of blockgroups.
> Is that not the case?

The reservation window code kind of knows the group boundaries. The
reason why we did this was, we want to fit it into existing 
ext3_get_newblock() code easily. ext3_get_newblock() operates on each
group and passes a bitmap for each group to work on. The current code
looks for a reservation window in the given group (since we need bitmap to
verify that there is something allocatable in that group).  
To make the reservation window ignore groups, we may need to do some major 
surgery to ext3_get_newblock().

	
> > We are also looking at RB tree and see how we can make use of it. Our
> > problem is,  we are interested in finding out a big enough hole in the
> > tree to put our reservation. We need to look closely.

> This sounds awfully like get_unmapped_area().

That was the first place I looked, i need to look at it one more time to see
if we can reuse the logic.

Thanks,
Badari