From: Roman Mamedov <rm@romanrm.ru>
To: Jeff Johnson <jeff.johnson@aeoncomputing.com>
Cc: 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 22:44:46 +0600 [thread overview]
Message-ID: <20130327224446.287a114e@natsu> (raw)
In-Reply-To: <CAFCYAsfWTC+Yjkh-XO89M44bxt_7cjBB6kT+xdEfrr4L9QPZRw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1163 bytes --]
On Wed, 27 Mar 2013 09:23:52 -0700
Jeff Johnson <jeff.johnson@aeoncomputing.com> wrote:
> And yet I have this output from /proc/mdstat:
>
> md1 : active raid1 sdb3[1] sda3[0]
> 288567164 blocks super 1.1 [2/2] [UU]
> bitmap: 3/3 pages [12KB], 65536KB chunk
>
> It is very strange. the responsiveness on small file i/o tends to
> support the notion that this mirror really has a 64MB chunk size. This
> is practically an order of magnitude larger than what is prudent. The
> iowait on simple things like a sync or writing out small files seems
> to support what mdstat is reporting. Of course, I'd like to change
> this but how to do so without breaking the RAID or risking data is not
> obvious.
This is the array _bitmap_ chunk size. In simple terms, it determines
granularity of array resyncs on unclean shutdowns.
You can change it by
mdadm --grow /dev/md1 --bitmap=none
mdadm --grow /dev/md1 --bitmap=internal --bitmap-chunk=131072
But the size you already have is okay, there is no need to change it, and I'd
say certainly no need to lower it (this will decrease performance).
--
With respect,
Roman
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2013-03-27 16:44 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 [this message]
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
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=20130327224446.287a114e@natsu \
--to=rm@romanrm.ru \
--cc=jeff.johnson@aeoncomputing.com \
--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 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.