Re: [RFC, PATCH 0/2] xfs: dynamic speculative preallocation for delalloc

[Michael Monnerie <michael.monnerie@is.it-management.at>]

[-- Attachment #1.1: Type: Text/Plain, Size: 2325 bytes --]

On Montag, 18. Oktober 2010 Dave Chinner wrote:
> delalloc does not do any waiting. The system decides when to flush
> data to disk. We even do delalloc for sync writes - the system
> flushes the data to disk immediately instead of via memory pressure
> or background writeback.
> 
> > Isn't that controlled by the values of 
> > vm.dirty_background_bytes and vm.dirty_expire_centisecs and 
> > vm.dirty_writeback_centisecs?
> 
> Exactly.
> 
> > Then dirty_background_bytes would be the 
> > maximum possible delalloc size?
> 
> No. Those numbers control the amount of dirty pages in memory, not
> the amount of space we've allocated speculatively. Indeed, by
> definition speculative allocation past EOF means it is space that
> currently has no dirty pages.... ;)

The big picture is becoming clearer, but I still don't get it. So 
delalloc is not really about delayed allocation, but more a speculation 
about needed filesizes, combined with in-memory preallocation of 
physical blocks on the storage? So it's "future allocation with delayed 
data filling". Or what is "delayed allocation" refering to, when data 
can be on disk already?

You wrote in another mail:
> that is the default behaviour for _physical_ extent allocation
> on files larger than one stripe unit (i.e stripe aligned and sized
> allocation). That is very different from speculative allocation done
> at delayed allocation time, which is purely in-memory until physical
> allocation occurs

So when a file is slowly uploaded, delalloc can imagine it will be 1MB 
on disk, and reserve that space in-memory. And when a write occurs, 
because dirty_background_bytes is hit, the fragments will be written, 
and the full 1MB is physically reserved on disk. Then more data arrives, 
delalloc now imagines the file will be 100MB on disk, it will reserve 
that space, first in-memory and after the next buffer flush on disk. Is 
it like this?

-- 
mit freundlichen Grüssen,
Michael Monnerie, Ing. BSc

it-management Internet Services
http://proteger.at [gesprochen: Prot-e-schee]
Tel: 0660 / 415 65 31

****** Radiointerview zum Thema Spam ******
http://www.it-podcast.at/archiv.html#podcast-100716

// Wir haben im Moment zwei Häuser zu verkaufen:
// http://zmi.at/langegg/
// http://zmi.at/haus2009/

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs