On Mon, Oct 06, 2008 at 04:30:22PM -0400, Justin Piszcz wrote:
> Someone pointed me to the following paper:
> 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
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. ;)