From: Dave Chinner <david@fromorbit.com>
To: Jan Engelhardt <jengelh@medozas.de>
Cc: xfs@oss.sgi.com
Subject: Re: Many-metadata performance still at a loss
Date: Fri, 11 Mar 2011 12:10:24 +1100 [thread overview]
Message-ID: <20110311011024.GB15097@dastard> (raw)
In-Reply-To: <alpine.LNX.2.01.1103101507120.5379@obet.zrqbmnf.qr>
On Thu, Mar 10, 2011 at 03:14:34PM +0100, Jan Engelhardt wrote:
> Hi,
>
>
> Between 2.6.33 and 2.6.37 there was a lot of interesting announcements
> with regards to XFS performance. However, now that I booted into
> 2.6.37.2, I still see the metadata slowness from earlier.
> (Basically `time (tar -xf linux-2.6.37.tar.gz; sync)` - ext4 gets the
> job done in like 15-20 seconds, xfs is still syncing after 11 minutes.)
>
> Was there something I missed?
>
> # xfs_info /
> meta-data=/dev/md3 isize=256 agcount=32,
> agsize=11429117 blks
> = sectsz=512 attr=2
> data = bsize=4096 blocks=365731739,
> imaxpct=5
> = sunit=0 swidth=0 blks
> naming =version 2 bsize=4096 ascii-ci=0
> log =internal bsize=4096 blocks=32768, version=2
> = sectsz=512 sunit=0 blks, lazy-count=0
^^^^^^^^^^^^
> realtime =none extsz=4096 blocks=0, rtextents=0
You're using an old mkfs? At minimum, this should have lazy-count=1.
I'm also wondering about the fact this is a MD device but there is
no sunit/swidth set, and the agcount of 32 is not a default value,
either. Seems like you handrolled your mkfs parameters - it is
better to just use the defaults a recent mkfs sets....
Further - what is your storage configuration (e.g. what type of MD
raid are you using) and is the filesystem correctly aligned to the
storage? If you get these wrong, then nothing else you do will
improve performance.
What are your mount options - perhaps you've missed the fact that
the new functionality requires the "delaylog" mount option to be
added. Mind you, that is not a magic bullet - if the operation is
single threaded and CPU bound, delaylog makes no difference to
performance, and with lazy-count=0 then the superblock will still be
a major contention point and probably nullify any improvement
delaylog could provide..
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-03-11 1:07 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-10 14:14 Many-metadata performance still at a loss Jan Engelhardt
2011-03-10 15:51 ` Stan Hoeppner
2011-03-11 1:10 ` Dave Chinner [this message]
2011-03-11 1:56 ` Jan Engelhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110311011024.GB15097@dastard \
--to=david@fromorbit.com \
--cc=jengelh@medozas.de \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox