linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Keld Jørn Simonsen" <keld@keldix.com>
To: David Brown <david.brown@hesbynett.no>
Cc: linux-raid@vger.kernel.org
Subject: Re: Using of RAID10,offset for faster writes
Date: Sat, 9 Apr 2011 17:05:14 +0200	[thread overview]
Message-ID: <20110409150514.GA24675@www2.open-std.org> (raw)
In-Reply-To: <inphu9$5kl$1@dough.gmane.org>

On Sat, Apr 09, 2011 at 02:03:21PM +0200, David Brown wrote:
> During a discussion about RAID in another context (a Linux newsgroup), I 
> began thinking about the speeds of the different RAID10 layouts for 
> different usages.  RAID10,far is often the fastest choice for general 
> use - you get striped reads for large reads, and access times are good 
> because you can get the data from either disk.  The disadvantage is that 
> writes involve a lot of extra head movement, as you need copies of the 
> data on two widely separated areas on the each disk.  But for general 
> use, you read a lot more often than you write, so the tradeoff is worth it.
> 
> In the discussion we were looking particularly at swap space on RAID. 
> This is a usage that requires a lot of writing, especially small writes. 
>  Using the RAID10,offset layout should give you most of the benefits of 
> RAID10,far when it comes to reading - you don't get quite as efficient 
> block reads for large reads, but you can still do a lot of striping in 
> the reads.  And writes will involve far less head movement, and so 
> should complete faster.
> 
> Has anyone tried this, or done any benchmarking?
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Some tests indicate that the theoretical slower writing speed of
raid10,far tends to be minimized by the elevator algoritm for the disk.
Writes are normally just delivered to the kernel in-core buffers, and
then every 30 secs or so flushed to the disk. The elevator orders this
writing to minimize head movement. So there is almost no penalty for
writes for raid10,far. 

Anyway, for swapping the paetition siz is normally quite small, say 2 to
10 GB, and head movement is thus quite small.

Tests show that raid10,offset does not really stripe sequential reads.
Anyway it would be interesting to see tests on swapping on rid10,offset
vs raid10,far. I am not sure how to test it. But it could be load times
for eg. openoffice in a swapped state - loading a big app is one of the
areas where you would notice the speed most in a user environment. Tht
could be the reading test. For the writing test, one could operate with
a rather small swap  partition, and then load a lot of big apps.

Best regards
Keld



  reply	other threads:[~2011-04-09 15:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-09 12:03 Using of RAID10,offset for faster writes David Brown
2011-04-09 15:05 ` Keld Jørn Simonsen [this message]
2011-04-10  9:50   ` David Brown

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=20110409150514.GA24675@www2.open-std.org \
    --to=keld@keldix.com \
    --cc=david.brown@hesbynett.no \
    --cc=linux-raid@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).