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

[Andrew Morton <akpm@osdl.org>]

Badari Pulavarty <pbadari@us.ibm.com> wrote:
>
> > - Why do we discard the file's reservation on every iput()?  iput's are
> >   relatively common operations. (see fs/fs-writeback.c)
> 
> We just followed old prealloc code. Where ever preallocation is dropped
> we dropped reservation.  May be thats overkill. We will look at it.
> 
> Whats the best place to drop the reservation ?

You know, I wish I had an easy answer to that, but I don't.  It's a matter
of sticking a printk in there, running careful tests, making sure that
we're doing the right thing at the right time.

As we discussed earlier, it could be that in some some situations we should
hold onto the reservation window after the file has been closed - the
slowly-growing mbox or logfile problem.  But without causing bandwidth
regressions in the the many-small-files scenario.

> > - Have you tested and profiled this with a huge number of open files?  At
> >   what stage do we get into search complexity problems?
> 
> 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?

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