xfs
[Top] [All Lists]

Re: xfs performance problem

To: Linux fs XFS <xfs@xxxxxxxxxxx>
Subject: Re: xfs performance problem
From: pg_xf2@xxxxxxxxxxxxxxxxxx (Peter Grandi)
Date: Fri, 29 Apr 2011 16:00:35 +0100
In-reply-to: <4DB75C6D.1080901@xxxxxxxxxxx>
References: <4DB72084.8020205@xxxxxxxxxxx> <4DB74331.3030804@xxxxxxxxxxxxxxxxx> <4DB75C6D.1080901@xxxxxxxxxxx>
[ ... ]

> On my raid-1 ext3, extracting a kernel archive:
[ ... ]
> real    0m21.769s
[ ... ]
> real    2m20.522s

> This is of course with delaylog enabled. I don't think a
> difference of a factor 7 is normal, given that writing to a
> raid-0 (xfs numbers) is supposed to be faster than writing to
> raid-1 (ext3 numbers)

Indeed, and as some other commenters have tried to explain, in
most cases the wrong number is the one for 'ext3' on RAID1 (way
too small). Even the number for XFS and RAID0 'delaylog' is a
wrong number (somewhat small) in many cases.

There are 38000 files in 440MB in 'linux-2.6.38.tar', ~40% of
them are smaller than 4KiB and ~60% smaller than 8KiB. Also you
didn't flush caches, and you don't say whether the filesystems
are empty or full or at the same position on the disk.

Can 'ext3' really commit 1900 small files per second (including
directory updates) to a filesystem on a RAID1 that probably can
do around 100 IOPS? That would be amazing news.

Despite decades of seeing it happen, I keep being astonished by
how many people (some with decades of "experience") just don't
understand IOPS and metadata and commits and caching and who
think "performance" is whatever number they can get with their
clever "benchmarks".

[ ... ]

<Prev in Thread] Current Thread [Next in Thread>