linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stan Hoeppner <stan@hardwarefreak.com>
To: Mark Knecht <markknecht@gmail.com>
Cc: Roy Sigurd Karlsbakk <roy@karlsbakk.net>,
	Jeff Johnson <jeff.johnson@aeoncomputing.com>,
	Linux-RAID <linux-raid@vger.kernel.org>
Subject: Re: Possible to change chunk size on RAID-1 without re-init or destructive result?
Date: Wed, 27 Mar 2013 15:10:58 -0500	[thread overview]
Message-ID: <51535252.2080105@hardwarefreak.com> (raw)
In-Reply-To: <CAK2H+eczN+fqWJv0r6WTA871R__jrrybS9ObdZ9dx6mX+Z=HHw@mail.gmail.com>

On 3/27/2013 2:23 PM, Mark Knecht wrote:

> Note that another level of understanding (which I don't have) has to
> do with getting chunk sizes that work well for my needs. That's a
> whole other kettle of fish...
...
> mark@c2stable ~ $ cat /proc/mdstat
> Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
> md6 : active raid5 sdc6[1] sdd6[2] sdb6[0]
>       494833664 blocks super 1.1 level 5, 64k chunk, algorithm 2 [3/3] [UUU]
>       bitmap: 0/2 pages [0KB], 65536KB chunk
> 
> md3 : active raid6 sdd3[2] sdc3[1] sdb3[0] sde3[3] sdf3[5]
>       157305168 blocks super 1.2 level 6, 16k chunk, algorithm 2 [5/5] [UUUUU]
> 
> md7 : active raid6 sdd7[2] sdc7[1] sdb7[0] sde2[3] sdf2[4]
>       395387904 blocks super 1.2 level 6, 16k chunk, algorithm 2 [5/5] [UUUUU]
> 
> md126 : active raid1 sdb5[0] sdd5[2] sdc5[1]
>       52436032 blocks [3/3] [UUU]

Your problem isn't chunk sizes, but likely the 4 md/RAID devices atop
the same set of physical disks.  If you have workloads that are
accessing these md devices concurrently that will tend to wreak havoc
WRT readahead, the elevator, and thus the disk head actuators.  If these
are low RPM 'green' drives it will be exacerbated due to the slow
spindle speed.

The purpose of RAID is to prevent data loss when a drive fails.  The
purpose of striped RAID is to add performance atop that.  Thus you
normally have one RAID per set of physical disks.  The Linux md/RAID
driver allows you to stack multiple RAIDs atop one set of disks, thus
shooting yourself in the foot.  Look at any hardware RAID card, SAN
controller, etc, and none of them allow this--only one RAID per disk set.

At this point you obviously don't won't to blow away your current setup,
create one array and restore, as you probably don't have backups.
Reshaping with different chunk sizes won't gain you anything either.  So
about the only things you can optimize at this point are your elevator
and disk settings such as nr_requests and read_ahead_kb.  Switching from
CFQ to deadline could help quite a lot.

-- 
Stan


  reply	other threads:[~2013-03-27 20:10 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-27  5:30 Possible to change chunk size on RAID-1 without re-init or destructive result? Jeff Johnson
2013-03-27  5:56 ` Mikael Abrahamsson
2013-03-27  6:02 ` Roman Mamedov
2013-03-27 16:01 ` Roy Sigurd Karlsbakk
2013-03-27 16:23   ` Jeff Johnson
2013-03-27 16:44     ` Roman Mamedov
2013-03-27 19:36     ` Stan Hoeppner
2013-03-27 19:11   ` Stan Hoeppner
2013-03-27 19:23     ` Mark Knecht
2013-03-27 20:10       ` Stan Hoeppner [this message]
2013-03-27 21:06         ` Mark Knecht
2013-03-27 22:08           ` Stan Hoeppner
2013-03-27 22:18             ` Mark Knecht
2013-03-31 15:56               ` Stan Hoeppner
2013-03-31 17:15                 ` Mark Knecht
2013-03-31 17:41                   ` Stan Hoeppner
2013-03-31 17:56                     ` Mark Knecht
2013-04-01  0:28                       ` Stan Hoeppner
2013-04-01 16:46                         ` Mark Knecht
2013-04-02  1:15                           ` Brad Campbell

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=51535252.2080105@hardwarefreak.com \
    --to=stan@hardwarefreak.com \
    --cc=jeff.johnson@aeoncomputing.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=markknecht@gmail.com \
    --cc=roy@karlsbakk.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 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).