I think the bdflush defaults are (were?) something like 5 seconds for
metadata, and 30 seconds for file data. reiser4 should (if it doesn't
already) use the parameters set by sys_bdflush() to tune the writeout
intervals.
I would think that either:
a) A file was completely written in under 30 seconds (e.g. untar or gcc
or whatever else you are doing), so deferring allocation and writing
to disk does not help you at all.
b) A file is continuing to be written for more than 30 seconds that
has a very large amount of outstanding data which can be committed
to disk with (probably) the same read optimization quality as any
larger amount of data.
c) A file is continuing to be written for more than 30 seconds that
is growing slowly and no matter how long you defer the write you
will only get an incremental read layout. Presumably you could do
something to pre-allocate/reserve a bunch of space at the end of this
file as it continues to grow.
So, except for the very unusual case of files with lifespans between 30
seconds and 300 seconds, or files that are written to between those
intervals, I would guess that you are not gaining much extra benefit by
deferring the writes another 270 seconds.
Cheers, Andreas
-- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/