From: Dave Chinner <david@fromorbit.com>
To: Justin Piszcz <jpiszcz@lucidpixels.com>
Cc: xfs@oss.sgi.com, Lennart Hansen <lahansen@gmail.com>
Subject: Re: XFS: "slow at directory traversal .. after 3 years of use"
Date: Tue, 7 Oct 2008 09:31:41 +1100 [thread overview]
Message-ID: <20081006223141.GS30001@disturbed> (raw)
In-Reply-To: <alpine.DEB.1.10.0810061627260.15837@p34.internal.lan>
On Mon, Oct 06, 2008 at 04:30:22PM -0400, Justin Piszcz wrote:
> Someone pointed me to the following paper:
>
> http://www.stdlib.net/~colmmacc/Apachecon-EU2005/scaling-apache-handout.pdf
>
> Which states:
>
> After nearly 3 years of use, some problems with XFS became
> noticeable. As the number of used inodes in the filesystem grows
> XFS becomes very slow at directory traversal. Although this did
> not impede web-serving it did have a heavy impact on how quickly
> we could synchronise content with the primary sources.
There's no detail of what the problem was, just that it slowed down.
Could have been many things, and one of the possibilities was the
in-core XFS inode hash scalability problems (that you could work
around with an ihashsize=XXX mount option)....
> Dave / Eric, comments here? Does ext3 suffer from the same
> problem?
An ext3 filesystem being faster than a 3 year old production XFS
filesystem - no surprise there as the XFS directories were probably
fragmented. After three years of continual use, I'd be extremely
surprised if the ext3 H-tree directory structures perform anywhere
near as well as XFS as the fragmentation characteristics of ext3
directories are far worse than XFS and ext3 does not have directory
readahead like XFS does.
An example - kernel.org moved from ext3 to XFS primarily because
the directory performance of XFS is better than ext3 on these
sorts of workloads....
> Have these issues been fixed since 2005? Would inode64 alleviate
> some of these problems?
Well, the incore inode hashes have no problems now they have been
converted to radix trees. Witout any further detail of what the
problem was, I can't really say anything else....
Barry - sounds like you need to make xfs_fsr defrag directories. ;)
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
prev parent reply other threads:[~2008-10-06 22:32 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1c08324d0810061325kdd1453alb9eab9ceb769b1cf@mail.gmail.com>
2008-10-06 20:30 ` XFS: "slow at directory traversal .. after 3 years of use" Justin Piszcz
2008-10-06 22:31 ` Dave Chinner [this message]
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=20081006223141.GS30001@disturbed \
--to=david@fromorbit.com \
--cc=jpiszcz@lucidpixels.com \
--cc=lahansen@gmail.com \
--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