Re: Why we need delayed allocation!

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... 
It sounds the requirement is "on *any* writepage to a not-yet-allocated
page the filesystem needs to allocate all not-yet-allocated pages in
strict file position order", which will be a relatively long time of
running sequential/serialized code (well prealloc will help there).
Maybe the filesystem can optimize this latency hit in the VM a bit in
the typical case by starting this process of allocating already on say
closing of the file by the writer (eg before the VM gets involved) .

Another thing to consider as alternative/helper is give applications the
possibility to tell the fs how big the file is going to be; apps like
tar, cpio, cp and ld can then use this and the fs can just prealloc the
entire file.

signature.asc
Description: This is a digitally signed message part