From: NeilBrown <neilb@suse.de>
To: Adam Goryachev <mailinglists@websitemanagers.com.au>
Cc: stan@hardwarefreak.com, linux-raid@vger.kernel.org
Subject: Re: Can't expand linear RAID on top of 2 x RAID1
Date: Mon, 25 Jun 2012 12:52:24 +1000 [thread overview]
Message-ID: <20120625125224.6e33b342@notabene.brown> (raw)
In-Reply-To: <32a64312-93cd-47d7-9154-2e28eda58003@email.android.com>
[-- Attachment #1: Type: text/plain, Size: 3925 bytes --]
On Sat, 23 Jun 2012 12:53:12 +1000 Adam Goryachev
<mailinglists@websitemanagers.com.au> wrote:
> Stan Hoeppner <stan@hardwarefreak.com> wrote:
>
> >On 6/22/2012 5:41 AM, Adam Goryachev wrote:
> >> I have expanded my system over time, I started with 2 x 2TB drives in
> >> RAID1 (md2)
> >>
> >> I then added 2 x 750GB drives, configured as RAID1 (md1)
> >> Then created a third raid (md3) as linear with the md2 + md1
> >>
> >> Finally, I've upgraded the 2 x 750G to 2 x 1TB drives (one at a
> >time).
> >>
> >> I then did a mdadm --grow to expand the RAID1 from 750G to 1TB
> >>
> >> The problem I am having is that I can't expand the linear (md3) array
> >to
> >> grow the extra 250G of space.
> >>
> >> Could anyone suggest how I might be able to get the extra 250G of
> >space
> >> to become available?
> >
> >If you think about this for a few minutes more, and re-read how md
> >--linear works, and thus how growing a linear array works, you'll
> >surely
> >understand why you can't do what you're attempting to do.
>
> Actually, no I don't understand the problem... From my (probably limited) understanding, linear simply appends each drive to the array. I understand that you would not be able to increase the size of any constituent device which is not the last component of the array, but I don't see any reason why it is not possible to increase the size of the last component. (Which is what I am attempting to do)
>
> >As for seeing that extra 250GB, I don't have an answer. Typically
> >linear arrays are used in lieu of growing constituent member arrays.
> >That's kinda the whole point of linear (concatenation).
>
> Well, the only other alternative I can think of is to reduce the size of the array back to 750G, reduce the size of the partitions for that array to 750G. Then create a new 250G partition on the two 1TB drives, create a fourth RAID1 array, and then add that 4th RAID1 array to the end of the existing linear array. This just didn't seem like a very good solution (ie, not clean).
>
> >You could try deleting the linear array and simply creating a new one.
> >But surely the changed offsets would wreak havoc on the filesystem
> >currently spanning this mess.
>
> Perhaps this would work. If I delete the linear array and re-create, with assume-clean (or whatever the right flag is, I'll read the man page later when I'm doing it), then like I said, the first component device will be the same, the second component device is the same, but just happens to be bigger. Any comments on whether this should work?
The is no '--assume-clean' for linear. Linear arrays cannot be clean or
dirty as md stores no redundant information.
Just re-creating the array would probably work, but there is an easier way.
md doesn't record the size of the array for Linear and RAID0. It just adds
together the sizes of the devices that it finds.
With 1.x metadata, md does record the effective size of each devices, so adds
those together.
You can update this effective size by assembling with
--update=devicesize
I just checked this will loop devices and it works as expected (assuming you
have 1.1 or 1.2 metadata).
So:
mdadm -S /dev/md2
mdadm -A --update=devicesize /dev/md0 /dev/md1
(order doesn't matter with assemble).
>
> What should I do to ensure that the component devices are ordered the way I think they are? Apparently the numbers in /proc/mdstat just tell me what order the devices were added, not what order they are in the array?
mdadm --detail or mdadm --examine would tell you what you want to know.
NeilBrown
>
> Thank you for your advice.
>
> Regards,
> Adam
>
>
>
> --
> 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next prev parent reply other threads:[~2012-06-25 2:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-22 10:41 Can't expand linear RAID on top of 2 x RAID1 Adam Goryachev
2012-06-22 23:05 ` Stan Hoeppner
2012-06-23 2:53 ` Adam Goryachev
2012-06-23 12:18 ` Stan Hoeppner
2012-06-24 14:17 ` Stan Hoeppner
2012-06-25 2:52 ` NeilBrown [this message]
2012-06-29 7:53 ` Adam Goryachev
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=20120625125224.6e33b342@notabene.brown \
--to=neilb@suse.de \
--cc=linux-raid@vger.kernel.org \
--cc=mailinglists@websitemanagers.com.au \
--cc=stan@hardwarefreak.com \
/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).