public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Stan Hoeppner <stan@hardwarefreak.com>
To: Peter Grandi <pg@xfs.list.sabi.co.UK>, Linux fs XFS <xfs@OSS.SGI.com>
Subject: Re: Problem about very high Average Read/Write Request Time
Date: Sat, 25 Oct 2014 14:31:06 -0500	[thread overview]
Message-ID: <544BFA7A.2070504@hardwarefreak.com> (raw)
In-Reply-To: <21579.33469.878654.99125@tree.ty.sabi.co.uk>

On 10/25/2014 06:00 AM, Peter Grandi wrote:
...
> Another poster went far further in guesswork, and stated what I
> was describing as guesses instead as obvious facts:
> 
>   http://oss.sgi.com/archives/xfs/2014-10/msg00337.html
>   > As others mentioned this isn't an XFS problem. The problem is that
>   > your RAID geometry doesn't match your workload. Your very wide
>   > parity stripe is apparently causing excessive seeking with your
>   > read+write workload due to read-modify-write operations.

When a parity array's throughput drops 2 orders of magnitude, from ~1.5
GB/s to 100 MB/s, RMW is historically the most likely cause, especially
with such a wide stripe.  So yes, this is a guess, but an educated one.

> and went on to make a whole discussion wholly unrelated to XFS
> based on that:
> 
>   > To mitigate this, and to increase resiliency, you should
>   > switch to RAID6 with a smaller chunk. If you need maximum
>   > capacity make a single RAID6 array with 16 KiB chunk size.
>   > This will yield a 496 KiB stripe width, increasing the odds
>   > that all writes are a full stripe, and hopefully eliminating
>   > much of the RMW problem.
>   
>   > A better option might be making three 10 drive RAID6 arrays
>   > (two spares) with 32 KiB chunk, 256 KiB stripe width, and
>   > concatenating the 3 arrays with mdadm --linear.

XFS is a layer of the Linux IO stack, and none of these layers exist in
isolation.  If someone using XFS has a problem and it may not be XFS
specific, we're still going to lend assistance where we can.

> The above assumptions and offtopic suggestions have been
> unquestioned; by myself too, even if I disagree with some of the
> recommendations, also as I think them premature because we don't
> know what the requirements really are beyond what can be guessed
> from «the reported information». That's also why I suggested to
> continue the discussion on the Linux RAID list.

If you haven't noticed Peter, the Chinese guys seem to post once and
never come back.  I don't know if this is a cultural thing or other, but
that's the way they seem to operate.  There is rarely interaction with
them, no follow ups, no additional information provided.  So I tend to
give them many ideas on the obvious path to work with in my reply, after
asking for additional information, which will likely never arrive.
Moving the thread to linux-raid wouldn't help.

And I'm sure you know Dave didn't come down on you due to the guesswork
in your posts, but because of your delivery style, and attitude and
behavior towards others.  It seems the latter prompted his critique of
the former.

Cheers,
Stan

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

  reply	other threads:[~2014-10-25 19:30 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-18  9:26 Problem about very high Average Read/Write Request Time quanjun hu
2014-10-18 12:38 ` Emmanuel Florac
2014-10-19 10:10   ` Peter Grandi
2014-10-20  8:00     ` Bernd Schubert
2014-10-21 18:27       ` Peter Grandi
2014-10-23 16:20         ` Bernd Schubert
2014-10-23 20:09           ` Peter Grandi
2014-10-24 21:45             ` Dave Chinner
2014-10-25 11:00               ` Peter Grandi
2014-10-25 19:31                 ` Stan Hoeppner [this message]
2014-10-25 12:36               ` Peter Grandi
2014-10-23 23:01           ` Peter Grandi
2014-10-19 21:16 ` Stan Hoeppner

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=544BFA7A.2070504@hardwarefreak.com \
    --to=stan@hardwarefreak.com \
    --cc=pg@xfs.list.sabi.co.UK \
    --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