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
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
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
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 ******
// Wir haben im Moment zwei Häuser zu verkaufen:
Description: This is a digitally signed message part.