xfs
[Top] [All Lists]

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

To: Michael Monnerie <michael.monnerie@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [RFC, PATCH 0/2] xfs: dynamic speculative preallocation for delalloc
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Fri, 15 Oct 2010 22:45:08 +1100
Cc: xfs@xxxxxxxxxxx, Ivan.Novick@xxxxxxx, aelder@xxxxxxx
In-reply-to: <201010150914.55604@xxxxxx>
References: <C8DCC927.48D3%ivan.novick@xxxxxxx> <201010150914.55604@xxxxxx>
User-agent: Mutt/1.5.20 (2009-06-14)
On Fri, Oct 15, 2010 at 09:14:54AM +0200, Michael Monnerie wrote:
> On Donnerstag, 14. Oktober 2010 Ivan.Novick@xxxxxxx wrote:
> > I have seen ~50% performance improvement in read rate when changing
> > from small extents to large extents with XFS. Essentially going from
> > not using allocsize to setting 1gb allocsize.  Also GB/s class
> > filesystem.
> 
> In case of a database, I'd say 1GB allocsize seems fine. But when you're 
> at /var/log/, it could be a penalty, as when you have 50 open log files 
> which get permanently appended, you have 50GB preallocated which almost 
> surely won't be needed before the log is rotated anyway.

Don't put your high performance database on the same filesystem as
your system log files. Or don't use tunings for databases on your
root filesystem.

> The question is: what is a good value for preallocation?

If you can't answer that, use the defaults.

> I'd guess for a database 1GB seems reasonable,

depends on  your database. If it does direct IO, then allocsize is
completely meaningless....

> for /var/log one full 
> stripe (nr-data-disks * stripe size),

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.

> for webserver/ftp data too, as 
> well as a fileserver (storing office documents) and mailserver (storing 
> each mail as a separate file or into one flat file).
> Or, when you have an app that writes files of specific size, use the 
> "normal maximum" file size. We have a special server storing files of 
> normally 50M-1G size, there I set allocsize=1024k, so that files will be 
> in one junk on disk. When sometimes a file is bigger, then it will be 
> fragmented but at reasonable sizes so it won't matter too much.
> 
> Is that reasonable?

What is reasonable is that the default behaviour does the right
thing. :)

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

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>