Re: Lazy block allocation and block_prepare_write?

[Mingming Cao <cmm@us.ibm.com>]

On Tue, 2005-04-19 at 19:55 +0400, Nikita Danilov wrote:
> Badari Pulavarty <pbadari@us.ibm.com> writes:
> 
> > On Tue, 2005-04-19 at 04:22, Nikita Danilov wrote:
> >> Badari Pulavarty <pbadari@us.ibm.com> writes:
> >> 
> >> [...]
> >> 
> >> >
> >> > Yes. Its possible to do what you want to. I am currently working on
> >> > adding "delayed allocation" support to ext3. As part of that, We
> >> 
> >> As you most likely already know, Alex Thomas already implemented delayed
> >> block allocation for ext3.
> >
> > Yep. I reviewed Alex Thomas patches for delayed allocation. He handled
> > all the cases in his code and did NOT use any mpage* routines to do
> > the work. I was hoping to change the mpage infrastructure to handle
> > these, so that every filesystem doesn't have to do their thing.
> >
> 
> Just keep in mind that filesystem != ext3. :-) Generic support makes
> sense only when it is usable by multiple file systems. This is not
> always possible, e.g., there is no "generic block allocator" for
> precisely the same reason: disk space allocation policies are tightly
> intertwined with the rest of file system internals.
> 

This generic support should be useful for ext2 and xfs. From delayed
allocation point of view, it should not aware any filesystem specific
block allocation policies, and it should not care.:)  It just simply
gathering all pages that need to map block on disk, and asking the
filesystem get_blocks() call back function, which will take care of the
filesystem-specific multiple blocks mapping for it.

Current get_blocks() function for ext3 is just simply loop calling
ext3_get_block().  I am trying to add a real ext3_get_blocks() to reduce
the cpu cost, reduce the number of metadata updates and increase the
possibility to get contiguous blocks on disk.