All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jim Mauro <James.Mauro@Sun.COM>
To: "Jeffrey W. Baker" <jwbaker@acm.org>
Cc: zfs-discuss@opensolaris.org, linux-ext4@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: ZFS, XFS, and EXT4 compared
Date: Thu, 30 Aug 2007 14:33:48 -0400	[thread overview]
Message-ID: <46D70D8C.8010203@sun.com> (raw)
In-Reply-To: <1188454611.23311.13.camel@toonses.gghcwest.com>


I'll take a look at this. ZFS provides outstanding sequential IO performance
(both read and write). In my testing, I can essentially sustain 
"hardware speeds"
with ZFS on sequential loads. That is, assuming 30-60MB/sec per disk 
sequential
IO capability (depending on hitting inner or out cylinders), I get 
linear scale-up
on sequential loads as I add disks to a zpool, e.g. I can sustain 
250-300MB/sec
on a 6 disk zpool, and it's pretty consistent for raidz and raidz2.

Your numbers are in the 50-90MB/second range, or roughly 1/2 to 1/4 what was
measured on the other 2 file systems for the same test. Very odd.

Still looking...

Thanks,
/jim

Jeffrey W. Baker wrote:
> I have a lot of people whispering "zfs" in my virtual ear these days,
> and at the same time I have an irrational attachment to xfs based
> entirely on its lack of the 32000 subdirectory limit.  I'm not afraid of
> ext4's newness, since really a lot of that stuff has been in Lustre for
> years.  So a-benchmarking I went.  Results at the bottom:
>
> http://tastic.brillig.org/~jwb/zfs-xfs-ext4.html
>
> Short version: ext4 is awesome.  zfs has absurdly fast metadata
> operations but falls apart on sequential transfer.  xfs has great
> sequential transfer but really bad metadata ops, like 3 minutes to tar
> up the kernel.
>
> It would be nice if mke2fs would copy xfs's code for optimal layout on a
> software raid.  The mkfs defaults and the mdadm defaults interact badly.
>
> Postmark is somewhat bogus benchmark with some obvious quantization
> problems.
>
> Regards,
> jwb
>
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>   

WARNING: multiple messages have this Message-ID (diff)
From: Jim Mauro <James.Mauro@Sun.COM>
To: "Jeffrey W. Baker" <jwbaker@acm.org>
Cc: zfs-discuss@opensolaris.org, xfs@oss.sgi.com, linux-ext4@vger.kernel.org
Subject: Re: [zfs-discuss] ZFS, XFS, and EXT4 compared
Date: Thu, 30 Aug 2007 14:33:48 -0400	[thread overview]
Message-ID: <46D70D8C.8010203@sun.com> (raw)
In-Reply-To: <1188454611.23311.13.camel@toonses.gghcwest.com>


I'll take a look at this. ZFS provides outstanding sequential IO performance
(both read and write). In my testing, I can essentially sustain 
"hardware speeds"
with ZFS on sequential loads. That is, assuming 30-60MB/sec per disk 
sequential
IO capability (depending on hitting inner or out cylinders), I get 
linear scale-up
on sequential loads as I add disks to a zpool, e.g. I can sustain 
250-300MB/sec
on a 6 disk zpool, and it's pretty consistent for raidz and raidz2.

Your numbers are in the 50-90MB/second range, or roughly 1/2 to 1/4 what was
measured on the other 2 file systems for the same test. Very odd.

Still looking...

Thanks,
/jim

Jeffrey W. Baker wrote:
> I have a lot of people whispering "zfs" in my virtual ear these days,
> and at the same time I have an irrational attachment to xfs based
> entirely on its lack of the 32000 subdirectory limit.  I'm not afraid of
> ext4's newness, since really a lot of that stuff has been in Lustre for
> years.  So a-benchmarking I went.  Results at the bottom:
>
> http://tastic.brillig.org/~jwb/zfs-xfs-ext4.html
>
> Short version: ext4 is awesome.  zfs has absurdly fast metadata
> operations but falls apart on sequential transfer.  xfs has great
> sequential transfer but really bad metadata ops, like 3 minutes to tar
> up the kernel.
>
> It would be nice if mke2fs would copy xfs's code for optimal layout on a
> software raid.  The mkfs defaults and the mdadm defaults interact badly.
>
> Postmark is somewhat bogus benchmark with some obvious quantization
> problems.
>
> Regards,
> jwb
>
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>   

  parent reply	other threads:[~2007-08-30 18:33 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-30  6:16 ZFS, XFS, and EXT4 compared Jeffrey W. Baker
2007-08-30  6:25 ` Cyril Plisko
2007-08-30  6:25   ` [zfs-discuss] " Cyril Plisko
2007-08-30  6:27 ` mike
2007-08-30  7:07 ` Nathan Scott
2007-08-30 13:20   ` Christoph Hellwig
2007-08-30 18:57     ` Eric Sandeen
2007-08-30 19:09       ` Jeffrey W. Baker
2007-08-30 19:09         ` Jeffrey W. Baker
2007-08-30 19:14         ` Eric Sandeen
2007-08-30 22:42     ` Nathan Scott
2007-09-01 15:07       ` Federico Sevilla III
2007-09-02 23:00         ` Nathan Scott
2007-08-30 13:37 ` Jose R. Santos
2007-08-30 18:52   ` Jeffrey W. Baker
2007-08-30 19:53     ` Jose R. Santos
2007-08-30 18:33 ` Jim Mauro [this message]
2007-08-30 18:33   ` [zfs-discuss] " Jim Mauro
2007-08-30 19:07 ` eric kustarz
2007-08-30 19:07   ` [zfs-discuss] " eric kustarz

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=46D70D8C.8010203@sun.com \
    --to=james.mauro@sun.com \
    --cc=jwbaker@acm.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=xfs@oss.sgi.com \
    --cc=zfs-discuss@opensolaris.org \
    /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.