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