From: Chris Webb <chris@arachsys.com>
To: NeilBrown <neilb@suse.de>
Cc: linux-raid@vger.kernel.org
Subject: Re: Assume-clean for md grow
Date: Thu, 26 Feb 2009 15:57:43 +0000 [thread overview]
Message-ID: <20090226155743.GM17577@arachsys.com> (raw)
In-Reply-To: <20090226145442.GH17577@arachsys.com>
Chris Webb <chris@arachsys.com> writes:
> NeilBrown <neilb@suse.de> writes:
>
> > Or if you want to be slightly more subtle, remove the
> > if (mddev->pers)
> > return -EBUSY;
> > from resync_start_store. Then before a grow that you want to be
> > --assume-clean, write into /sys/block/mdXX/md/resync_start the
> > number of sectors in the final raid1 array.
>
> Hi Neil. Thanks for this suggestion: it looks fine for what we're looking to
> achieve. Interestingly, this will mean writing a smaller value that shown by
> a read from this file for an in-sync array, but will still work?
For instance,
3# cat /sys/block/md127/{size,md/resync_start}
2097136
18446744073709551615
I just tried growing the slots up from 1G to 3G, then
echo $((2097136 + 2*1024*1024*2)) >/sys/block/md127/md/resync_start
mdadm --grow 3145720
but this gives me
md127 : active raid1 dm-3[1] dm-2[0]
3145720 blocks super 1.1 [2/2] [UU]
resync=PENDING
in /proc/mdstat, which is presumably not right?
Does this sysfs file hold the size of the array or the size of the
components, for implementing the non-RAID1 case?
Also, if I don't know the size of the final array[1], is it safe to write a
value much larger than the size of the array in here, or will that cause
future grows to be clean when this isn't necessarily intended?
[1] One of the things which has been most awkward with using md as part of a
automated storage system has been going from component size to available
array size and back again, given that bitmap reservation depends on the
original size of the array not the current size of the array. (In the end,
we've cheated and always written everything in terms of change in component
size vs change in array size, and been generous with the amount of space we
allocate to components on initial device create. It does feel like I'm
coding far too much knowledge of the internal choices mdadm makes into my
management layer, though!)
Cheers,
Chris.
next prev parent reply other threads:[~2009-02-26 15:57 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-25 14:22 Assume-clean for md grow Chris Webb
2009-02-25 19:34 ` NeilBrown
2009-02-26 14:54 ` Chris Webb
2009-02-26 15:57 ` Chris Webb [this message]
2009-02-26 16:03 ` Chris Webb
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=20090226155743.GM17577@arachsys.com \
--to=chris@arachsys.com \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.de \
/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).