Re: Why we need delayed allocation!

Hello!

On Fri, Dec 26, 2003 at 01:07:03PM +0300, Nikita Danilov wrote:
>  > > Preallocation would have solved this problem somewhat, but it isn't a
>  > > perfect solution given much larger executables (such as Mozilla or
>  > > Evolution).  Something that would work much better would be to use
>  > > delayed allocation, where we don't actually try to determine the
>  > > placement of the blocks of a file until we are asked to write the page
>  > > from the page cache. 
>  > 
>  > the direct approach of allocating the block on writepage doesn't help
>  > the fragmentation reliably; eg it depends on the VM having a specific
>  > order of calling writepage. In the case of the linker above, the VM will
>  > most likely have a strict LRU order, eg call writepage in the order the
>  > app wrote the pages... 
> One can do block allocation from ->writepages() (i.e., when writer is
> throttled by balance_dirty_pages(), or from pdflush), like reiser4
> does. ->writepages() operates on the whole file, so allocation will not
> depend on the order of pages in the VM lists.

reiser4 maintains sorted list of jnodes, I think.
Filesystems that depend on page lists that are stored in VM would still need to
sort those lists first.

Bye,
    Oleg


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click