Re: Why we need delayed allocation!

Alex Tomas writes:
 > >>>>> Nikita Danilov (ND) writes:
 > 
 >  ND> One can do block allocation from ->writepages() (i.e., when writer is
 >  ND> throttled by balance_dirty_pages(), or from pdflush), like reiser4
 >  ND> does. ->writepages() operates on the whole file, so allocation will not
 >  ND> depend on the order of pages in the VM lists.
 > 
 > actually, this is what I do. ->writepages() tries to find unallocated
 > extents, allocate them and calls mpage_writepages() to do real flushing.
 > 

One lesson we learned in reiser4 is that delayed allocation done at the
memory pressure (that is, from ->writepage()) doesn't play well with
extents. If file system uses extents to keep track of where file's
blocks are, and extents are initially "unallocated" then at the
->writepage() time one has to allocate them. This leads to all sorts of
nasty worst cases and deadlocks, because during allocation single
unallocated extent can be split into many allocated ones (due to bitmap
fragmentation), which requires insertion of these new extents, which is
too late to do safely at the ->writepage() time, because you are out of
memory already.

Just thought this may be of interest for you, as ext* is going to have
extents also.

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