linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stan Hoeppner <stan@hardwarefreak.com>
To: Phil Turmel <philip@turmel.org>
Cc: Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: "Missing" RAID devices
Date: Thu, 23 May 2013 00:59:39 -0500	[thread overview]
Message-ID: <519DB04B.5030505@hardwarefreak.com> (raw)
In-Reply-To: <519D541B.1090508@turmel.org>

On 5/22/2013 6:26 PM, Phil Turmel wrote:
> On 05/22/2013 06:43 PM, Stan Hoeppner wrote:
>> Sorry for the dup Phil, hit the wrong reply button.
> 
> No worries.
> 
>> On 5/21/2013 7:02 PM, Phil Turmel wrote:
>> ...
>>> ...First is /dev/md1, a small (~500m) n-way
>>> ...as /boot.  The other, /dev/md2, uses
>>> ...raid10,far3 or raid6.
>>>
>>> I put LVM on top of /dev/md2, with LVs for swap, ... /tmp
>>
>> Swap and tmp atop an LV atop RAID6?  The former will always RMW on page
>> writes, the latter quite often will cause RMW.  As you stated your
>> performance requirements are modest.  However, for the archives, putting
>> swap on a parity array, let alone a double parity array, is not good
>> practice.
> 
> Ah, good point.  Hasn't hurt me yet, but it would if I pushed anything
> hard.  I'll have to revise my baseline to always have a small raid10,f3
> to go with the raid6.

Yeah, the kicker here is that swap on a parity array seems to work fine,
right up until the moment it doesn't.  And that's when the kernel goes
into heavy swapping due to any number of causes.  When that happens,
you're heavily into RMW, disk heads are bang'n, latency goes through the
roof.  If any programs are trying to access files on the parity array,
say a mildly busy IMAP, FTP, etc, server, everything grinds to a halt.

With your particular setup, instead you might use n additional
partitions, one each across the physical disks that comprise your n-way
RAID1.  You would configure the partition type of each as (82) Linux
swap, and add them all to fstab with equal priority.  The kernel will
interleave the 4KB swap page writes evenly across all of these
partitions, yielding swap performance similar to an n-way RAID0 stripe.

The downside to this setup is the kernel probably crashes if you lose
one of these disks and thus the swap partition on it.  So you could
simply make another md/RAID1 of these n partitions if n is an odd number
of spindles.  Or n/2 RAID1 arrays if n is even.  Then put one swap
partition on each RAID1 device and do swap interleaving across the RAID1
pairs as described above in the non RAID case.

The reason for this last configuration is simple-- more swap throughput
for the same number of physical writes.  With a 4 drive RAID1 and a
single swap partition atop, each 4KB page write to swap generates a 4KB
write to each of the 4 disks, 16KB total.  If you create two RAID1s and
put a swap partition on each and interleave them, each 4KB page write to
swap generates only two 4KB writes, 8KB total.  Here for each 16KB
written you're moving two pages to swap instead of one.  Thus your swap
bandwidth is doubled.  But you still have redundancy and crash avoidance
if one disk fails.  You may be tempted to use md/RAID10 of some layout
to optimize for writes, but you'd gain nothing, and you'd lose some
performance due to overhead.  The partitions you'll be using in this
case are so small that they easily fit in a single physical disk track,
thus no head movement is required to seek between sectors, only rotation
of the platter.

Another advantage to this hybrid approach is less disk space consumed.
If you need 8GB of swap, a 4-way RAID1 swap partition requires 32GB of
disk space, 8GB per disk.  With the n/2 RAID1 approach and 4 disks it
requires half that, 16GB.  With the no redundancy interleaved approach
it requires 1/4th, only 2GB per disk, 8GB total.  With today's
mechanical disk capacities this isn't a concern.  But if using SSDs it
can be.

> Meanwhile, I'm applying some of the general ideas I've seen from you:
> I've acquired a pair of Crucial M4 SSDs for my new home media server to
> keep small files and databases away from the bulk storage.  Not in
> service yet, but I'm very pleased so far.

If the two are competing for seeks thus slowing everything down, moving
the random access stuff to SSD should help.

> I'm pretty sure the new kit is way overkill for a media server... :-)

Not so many years ago folks would have said the same about 4TB mech
drives. ;)

-- 
Stan


  reply	other threads:[~2013-05-23  5:59 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-21 12:51 "Missing" RAID devices Jim Santos
2013-05-21 15:31 ` Phil Turmel
2013-05-21 22:22   ` Jim Santos
2013-05-22  0:02     ` Phil Turmel
2013-05-22  0:16       ` Jim Santos
2013-05-22 22:43       ` Stan Hoeppner
2013-05-22 23:26         ` Phil Turmel
2013-05-23  5:59           ` Stan Hoeppner [this message]
2013-05-23  8:30             ` keld
2013-05-24  3:45               ` Stan Hoeppner
2013-05-24  6:32                 ` keld
2013-05-24  7:37                   ` Stan Hoeppner
2013-05-24 17:15                     ` keld
2013-05-24 19:05                       ` Stan Hoeppner
2013-05-24 19:22                         ` keld
2013-05-25  1:42                           ` Stan Hoeppner
2013-05-24  9:23                   ` David Brown
2013-05-24 18:03                     ` keld
2013-05-23  8:22           ` David Brown
2013-05-21 16:23 ` Doug Ledford
2013-05-21 17:03   ` Drew
     [not found]     ` <519BDC8C.1040202@hardwarefreak.com>
2013-05-21 21:02       ` Drew
2013-05-21 22:06         ` 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=519DB04B.5030505@hardwarefreak.com \
    --to=stan@hardwarefreak.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=philip@turmel.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).