xfs
[Top] [All Lists]

Re: mysterious dbench results

To: linux-xfs@xxxxxxxxxxx
Subject: Re: mysterious dbench results
From: G.Z. <mailus@xxxxxx>
Date: Fri, 23 Feb 2001 17:42:17 +0100
In-reply-to: <200102221504.f1MF41r20047@xxxxxxxxxxxxxxxxxxxx>
References: <200102221504.f1MF41r20047@xxxxxxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
On Thursday 22 February 2001 16:04, Steve Lord wrote:
> I have been out for a while, or I would have posted something on this
> earlier. The default mkfs options for xfs are not optimal for heavy I/O
> load, they are somewhat historical and should probably be changed.
>
> On mkfs try some options like this:
>
> mkfs -t xfs -f -l size=32768b /dev/xxx
>
> on mount use these extra options:
>
>       logbufs=4,logbsize=32768


Is there any way I can change those parameters on a premadf filesystem?

thanks in advance

-Giuseppe


>
> The first will make the on disk log bigger which helps metadata intensive
> loads not become purely log bound - every request for log space ends up
> having to flush metadata to disk. The mount options allow more log writes
> to be in progress at once.
>
> These should help XFS performance here, I suspect, but have not tried that
> this will also help:
>
> echo 5000 > /proc/sys/vm/pagebuf/flush_int
>
> This will make the interval between dirtying file data and flushing it to
> disk closer to that used by ext2. One of the issues with dbench is files
> getting removed shortly after they are created, you can get mush better
> performance if the removal happens before the data goes out to disk.
>
> In the long run Ananth's development direction is probably the correct fix
> for this, we would end up using the same mechanisms as other filesystems
> for controlling flushing file data to disk.
>
> Steve
>
> > Thomas Graichen <graichen@xxxxxxxxxxxxx> wrote:
> > > ok - now tested it on one machine once in smp and once in up mode
> > > and got the same results (very bad dbench results compared to
> > > ext2 or reiserfs) ... so it's not smp related - i'm right now
> > > updating the kernel and will post again - if the problem is
> > > still there ...
> >
> > ... and it is - so the question: anyone else seing this? - as said
> > dbench results are about 1/4th of ext2 results with the current
> > XFS tree on an ide disk system for smp and nosmp
> >
> > t

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