public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Stan Hoeppner <stan@hardwarefreak.com>
Cc: xfs@oss.sgi.com
Subject: Re: Xfs delaylog hanged up
Date: Wed, 24 Nov 2010 11:20:23 +1100	[thread overview]
Message-ID: <20101124002023.GA22876@dastard> (raw)
In-Reply-To: <4CEC3CB8.8000509@hardwarefreak.com>

On Tue, Nov 23, 2010 at 04:14:16PM -0600, Stan Hoeppner wrote:
> Dave Chinner put forth on 11/23/2010 2:46 PM:
> 
> > I've been unable to reproduce the problem with your test case (been
> > running over night) on a 12-disk, 16TB dm RAID0 array, but I'll keep
> > trying to reproduce it for a while. I note that the load is
> > generating close to 10,000 iops on my test system, so it may very
> > well be triggering load related problems in your raid controller...
> 
> Somewhat off topic, but how are you generating 10,000 IOPS by carving a
> 16TB LUN/volume from 12 x 2TB SATA disk spindles?  Such drives aren't
> even capable of 200 seeks per second.  Even if they were you'd top out
> at less than 2,500 IOPS (random).  16TB/12=1.33 TB per disk.  No such
> capacity disk exists.  So I assume you're using 12 x 2TB disks and
> slicing/dicing out 16TB.  What am I missing Dave?

512MB of BBWC backing the disks. The BBWC does a much better job of
reordering out-of-order writes than the Linux elevators because
512MB is a much bigger window than a couple of thousand 4k IOs.
Hence metadata/small file intensive workloads go much faster than
you'd expect from just looking at the IO patterns and the capability
of the disks.

IOWs, for write workloads that are not purely random, the disk
subsystem behaves more like an SSD than a RAID0 array of spinning
rust...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2010-11-24  0:18 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-22 19:27 Xfs delaylog hanged up Spelic
2010-11-22 23:29 ` Dave Chinner
2010-11-23 11:17   ` Spelic
2010-11-23 13:28     ` Spelic
2010-11-23 20:46     ` Dave Chinner
2010-11-23 22:14       ` Stan Hoeppner
2010-11-24  0:20         ` Dave Chinner [this message]
2010-11-24 13:12           ` Spelic
2010-11-24 21:50             ` Dave Chinner
2010-11-23 22:48       ` Emmanuel Florac
2010-11-24  0:36         ` Spelic
2010-11-24  1:40           ` Stan Hoeppner
2010-11-24  6:18           ` Michael Monnerie
2010-11-24  7:44           ` Emmanuel Florac
2010-11-24  0:58       ` Spelic
2010-11-24  5:44         ` Dave Chinner
2010-11-25 23:34       ` Spelic
2010-11-26  4:20         ` Dave Chinner
2010-11-24 22:52 ` Spelic
2010-11-26 22:43   ` Spelic
  -- strict thread matches above, loose matches on Subject: below --
2010-11-24  4:03 Richard Scobie

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=20101124002023.GA22876@dastard \
    --to=david@fromorbit.com \
    --cc=stan@hardwarefreak.com \
    --cc=xfs@oss.sgi.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox