From: Christoph Hellwig <hch@infradead.org>
To: Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>
Cc: Christoph Hellwig <hch@infradead.org>, linux-xfs@oss.sgi.com
Subject: Re: Deleting files with extended attributes is dead slow
Date: Wed, 17 Aug 2011 13:02:52 -0400 [thread overview]
Message-ID: <20110817170251.GB28650@infradead.org> (raw)
In-Reply-To: <4E4BBC98.7020501@itwm.fraunhofer.de>
On Wed, Aug 17, 2011 at 03:05:28PM +0200, Bernd Schubert wrote:
> >(squeeze-x86_64)fslab2:~# xfs_bmap -a /mnt/xfs/Bonnie.29243/00000/00000027faJxifNb0n
> >/mnt/xfs/Bonnie.29243/00000/00000027faJxifNb0n:
> > 0: [0..7]: 92304..92311
>
> (Sorry, I have no idea what "0: [0..7]: 92304..9231" is supposed to
> tell me).
It means that you are having an extent spanning 8 blocks for xattr
storage, that map to physical blocks 92304 to 9231 in the filesystem.
It sounds to me like your workload has a lot more than 256 bytes of
xattrs, or the underlying code is doing something rather stupid.
> Looking at 'top' and 'iostat -x' outout, I noticed we are actually
> not limited by io to disk, but CPU bound. If you should be
> interested, I have attached 'perf record -g' and 'perf report -g'
> outout, of the bonnie file create (create + fsetfattr() ) phase.
It's mostly spending a lot of time on copying things into the CIL
buffers, which is expected and intentional as that allows for additional
parallelity. I you'd switch the workload to multiple intances doing
the create in parallel you should be able to scale to better numbers.
> > 100:256:256/10 37026 91 +++++ +++ 43691 93 35960 92 +++++ +++ 40708 92
> >Latency 4328us 765us 2960us 527us 440us 1075us
> >1.96,1.96,fslab2,1,1313594619,,,,,,,,,,,,,,100,256,256,,10,37026,91,+++++,+++,43691,93,35960,92,+++++,+++,40708,92,,,,,,,4328us,765us,2960us,527us,440us,1075us
>
>
> xfs:
> mkfs.xfs -f -i size=512 -i maxpct=90 -l lazy-count=1 -n size=64k /dev/sdd
Do 64k dir blocks actually help you with the workload? They also tend
to do a lot of useless memcpys in their current form, although these
didn't show up on your profile. Did you try using a larger inode size
as suggested in my previous mail?
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-08-17 17:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-12 18:19 Deleting files with extended attributes is dead slow Bernd Schubert
2011-08-12 20:47 ` Christoph Hellwig
2011-08-16 16:13 ` Christoph Hellwig
[not found] ` <4E4BBC98.7020501@itwm.fraunhofer.de>
2011-08-17 17:02 ` Christoph Hellwig [this message]
2011-08-17 17:39 ` Bernd Schubert
2011-08-18 2:08 ` Dave Chinner
2011-08-18 3:05 ` Dave Chinner
2011-08-22 14:35 ` Christoph Hellwig
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=20110817170251.GB28650@infradead.org \
--to=hch@infradead.org \
--cc=bernd.schubert@itwm.fraunhofer.de \
--cc=linux-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