Re: Why we need delayed allocation!

Arjan van de Ven writes:
 > On Thu, 2003-12-25 at 20:27, Theodore Ts'o 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.

Nikita.


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