Re: Why we need delayed allocation!

probably, this would look crazy, but what about following:

1) at writeback time we can have in cache dirty pages to be flushed
   and clean pages we dont flush usually
2) if clean page(s) help to enlarge an extent(s) then we could unmap
   those clean pages and allocate new larger extent using them

>>>>> Arjan van de Ven (AvdV) writes:

 AvdV>    The most extreme form of this is an in-kernel-online-defragger 
 AvdV>    which would remap blocks of files which are very fragmented into
 AvdV>    a new contiguous area on the fly. This is a bit like the garbage
 AvdV>    collector in jffs2 and could use a "not fragmented" bit in the inode.
 AvdV>    Obviously this is considered bloat once mentioned out loud...
 AvdV>    Also the interactions with O_DIRECT and such a beast are beyond
 AvdV>    funny.



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