Miles Bader put forth on 4/21/2011 11:45 PM: > Stan Hoeppner <s...@hardwarefreak.com> writes: >> XFS beats EXT4 hands down in nearly every category, at least for server >> workloads. EXT4 may have some advantages on single user workstations >> simply from a familiarity standpoint WRT tools, and slightly better >> performance with some single user workloads. > > I had an account on a server where they switched to XFS (from ext3) > after a system upgrade. While XFS seemed to work well enough in > general, I encountered one starkly obvious problem with it: deleting > large trees of small files was _insanely_ slow (e.g. large source > trees), like a couple orders of magnitude slower than ext3.
Heheh, yes, it was slow as a turtle. :) Large amounts of metadata writes was always the Achilles heel of XFS, but, no more. The delayed logging patch introduced in 2.6.35 last year as experimental, in 2.6.37 as stable, and 2.6.39 as the default, increases metadata write performance by an order of magnitude, up to 100 fold and more in some cases. XFS is now on par with, or exceeds, EXT3/4 and Reiser WRT metadata performance. Maybe worth the read to some folks as to how it was done: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/xfs-delayed-logging-design.txt It's brilliant, really. Kudos to XFS develop Dave Chinner for inventing this. > A "rm -rf" that would take a few seconds with ext3 turned into a "go get > a coffee and read for a while" event. You're gonna miss that excuse to get coffee and a paper now. :) > [I haven't used that system regularly for a few years, so if that > behavior was due to an XFS bug, perhaps it's been fixed by now. > Still, I wouldn't consider switching to XFS without verifying that...] The horrible metadata performance wasn't due to a bug, but due to the fact that XFS was originally designed for maximum parallel streaming read/write performance with extremely large (multi gigabyte) files. Remember, XFS was born at SGI, and SGI's business is supercomputers. Supercomputer workloads don't involve lots of small files. When SGI open sourced XFS as part of their conversion from IRIX on MIPS to Linux on Intel Itanium, porting XFS to Linux in the process, more people threw general use workloads on top of XFS bringing this problem under brights lights. Dave Chinner worked for SGI for quite some time, then moved to Red Hat. It seems Red Hat's intention is to make XFS their default filesystem on RHEL at some point. Eliminating this horrible metadata performance problem was/is a prerequisite to doing so. Dave's patch has thoroughly eliminated the problem. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4db10e72.9070...@hardwarefreak.com
