All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Clements <paul.clements@steeleye.com>
To: Georgi Alexandrov <teh@amln.net>
Cc: linux-raid@vger.kernel.org
Subject: Re: write-behind performance ... or how behind can write-behind write
Date: Fri, 13 Feb 2009 13:44:37 -0500	[thread overview]
Message-ID: <4995BF95.1010908@steeleye.com> (raw)
In-Reply-To: <4995A170.4000000@amln.net>

Georgi Alexandrov wrote:

> Generally with the healthy array I'm getting the write performance of
> the SATA disk alone (in terms of requests/sec issued to the disk and
> bytes/sec written). The SATA disk is obviously a bottleneck even with
> the write-behind option set(2).

write-behind can help with two things:

1) overcoming latency (say one disk is on the network -- it may be the 
same speed as the source disk, but it takes longer round-trip for each 
I/O to complete)

2) temporary slowness of a device (say at a peak in I/O) -- the queue 
can temporarily hide the slowness of the secondary disk, but this won't 
last very long -- if writes continue at a pace faster than the disk can 
handle (i.e., the queue gets filled) then the array drops back to 
non-write-behind behavior

> So the questions is How behind can write-behind write? And can we get a
> better performance in a similar setup.

By default, it queues up 256 writes. This can be increased, but I've 
actually seen worse performance in some cases -- not sure why. I haven't 
had the time to dig into it and figure it out.

--
Paul

  reply	other threads:[~2009-02-13 18:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-13 16:36 write-behind performance ... or how behind can write-behind write Georgi Alexandrov
2009-02-13 18:44 ` Paul Clements [this message]
2009-02-14 13:38   ` Bill Davidsen
2009-02-16 10:39     ` Georgi Alexandrov

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=4995BF95.1010908@steeleye.com \
    --to=paul.clements@steeleye.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=teh@amln.net \
    /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.