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:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
