All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Baertschi <markus@markus.org>
To: Gary.Mansell@ricardo.com,
	LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] Why the dramatic increase in filesystem performance when usingxfs????
Date: Sat, 22 Jan 2005 14:25:55 +0100	[thread overview]
Message-ID: <41F25463.7020902@markus.org> (raw)
In-Reply-To: <1106304669.3943.14.camel@grma-lap>


If you browse through the extensive filesystem benchmarks at

http://fsbench.netnation.com/

You'll find results quite similar to yours. XFS is performing well for 
large sequential operations while ext3 without the writeback option can 
be half the speed.

I usually use ext3 for the OS volumes only, except with SuSE where 
reiser3 is the default. For other filesystems I prefer jfs for no 
exceptionally good reason but that I came to like it on AIX.

Markus


Gary Mansell wrote:
> Hi,
> 
> I have always run ext3 filesystem with journalling on Redhat AS as it is
> the only supported filesystem.
> 
> One of my colleagues runs xfs, though, and on comparable hardware
> configs he gets twice the performance compared to my ext3 tests.
> 
> The test that I perform is to create a file at least twice the size of
> the RAM installed in the system to avoid the possibility of cacheing,
> measuring the time to write and read the file back gives me the
> performance figure that I am after. I realise that this is a very simple
> test of large sequential IO but it is good enough for my needs.
> 
> ie
> 
> Write test:
> 
> # time dd if=/dev/zero of=./testfile bs=16384 count=250000 ; time sync
> 
> Read test:
> 
> # time dd if=./testfile of=/dev/null bs=16384
> 
> 
> As the xfs performance comes back about twice the performance of ext3
> for this test I am of the opinion that xfs must be cheating somehow. It
> has always been my opinion that the IO bottleneck is the hardware and
> not the filesystem hence changing the filesystem but using the same
> hardware should not make a huge difference to performance (you still
> have to get the same amount of data out to disk at the end of the day)
> 
> I am struggling to comprehend how xfs can cheat, though, as it can't
> cache such a huge file as there is not enough memory. Is it perhaps
> cheating because the file is comprised entirely of zero's?
> 
> Can someone please enlighten me
> 
> Thanks in advance
> 
> Gary Mansell


-- 
   Markus Baertschi             Phone: ++41 (21) 807 1677
   Bas du Ross� 14b             Fax  : ++41 (21) 807 1678
   CH-1163, Etoy                Email: markus@markus.org
   Switzerland                  Homepage: www.markus.org

      parent reply	other threads:[~2005-01-22 13:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-21 10:51 [linux-lvm] Why the dramatic increase in filesystem performance when usingxfs???? Gary Mansell
2005-01-21 16:24 ` Greg Freemyer
2005-01-24  0:32   ` Nathan Scott
2005-01-24 17:53     ` Greg Freemyer
2005-01-24 21:55       ` Nathan Scott
2005-01-24 23:35         ` [linux-lvm] XFS and snapshots [WAS: Re: Why the dramatic increase in filesystem performance when usingxfs????] Greg Freemyer
2005-01-25 17:36           ` Kristina Clair
2005-01-25 17:51             ` Greg Freemyer
2005-01-21 18:44 ` [linux-lvm] Why the dramatic increase in filesystem performance when usingxfs???? David S.
2005-01-22 13:25 ` Markus Baertschi [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=41F25463.7020902@markus.org \
    --to=markus@markus.org \
    --cc=Gary.Mansell@ricardo.com \
    --cc=linux-lvm@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.