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: 2615 bytes --]

On Freitag, 15. Oktober 2010 Dave Chinner wrote:
> On Fri, Oct 15, 2010 at 09:14:54AM +0200, Michael Monnerie wrote:
> > The question is: what is a good value for preallocation?
> 
> If you can't answer that, use the defaults.

Who can really without testing? For a webserver, hosting hundreds of 
different websites, with many ftp uploads and where the rest of the 
writes are webservers temp and log files, do you know the best value 
without investigation? That's what I meant.
 
> > I'd guess for a database 1GB seems reasonable,
> 
> depends on  your database. If it does direct IO, then allocsize is
> completely meaningless....

True, I was thinking of postgresql and mysql (innodb, 1 file per table). 
Both increment file sizes when needed.
 
> IIRC, 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.

Together with your other answer (swalloc...) I get the picture now. So 
delalloc, speculative prealloc, and physical allocation are done, where 
the first two are in-memory. And the mount option allocsize sets the 
delalloc size.
 
Now something comes to my mind: When I make an ftp upload, it's very 
slow in terms of disk speed. Say 2MB/s. How long would delalloc wait 
before flushing buffers on disk? 

Isn't that controlled by the values of 
vm.dirty_background_bytes and vm.dirty_expire_centisecs and 
vm.dirty_writeback_centisecs? Then dirty_background_bytes would be the 
maximum possible delalloc size? But it's value is the top for the whole 
machine, so it would need to be much higher than I want it to be for a 
specific filesystem.
Or are those values controllable per mount?

Sorry for my maybe boring questions, I'm trying to understand how to get 
the most out of a server with lot's of VMs, and tuning seems to help 
(and be needed) a lot in this situation.

> Nobody should need to use the allocsize mount option except in
> extreme corner cases, and that is what my patchset attempts to
> achieve.

Sounds good :-)

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