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