Re: file systems
Miles Bader put forth on 4/21/2011 11:45 PM:
> Stan Hoeppner <stan@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
Reply to: