All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.com>
To: Wakko Warner <wakko@animx.eu.org>, linux-raid@vger.kernel.org
Subject: Re: Shrinking an array
Date: Tue, 11 Apr 2017 14:33:24 +1000	[thread overview]
Message-ID: <87fuhfwokr.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <20170411003008.GA18538@animx.eu.org>

[-- Attachment #1: Type: text/plain, Size: 2102 bytes --]

On Mon, Apr 10 2017, Wakko Warner wrote:

> I have a question about shrinking an array.  My current array is 4x 2tb
> disks in raid6 (md0).  The array was created on the 2nd partition of each
> disk and spans most of the disk.  I would like to replace the 2tb disks with
> 750gb disks.  md0 is a luks container with lvm underneath.  I have less than
> 1tb actually in use.  What would the recommended procedure be for shrinking
> this?  I've watched this list, but I don't think I've come across anyone
> actually wanting to do this before.
> I'm thinking of these steps already:
> 1) Shrink PV.
> 2) Shrink luks.  I'm aware that there is not size metadata, but the dm
> mapping would need to be shrunk.
> 3) Shrink md0.  I did this once when I changed a 6 drive raid6 into a 5
> drive raid6.  Would I use --array-size= or --size= ?  I understand the
> difference is the size of md0 vs the individual members.

You don't need --array-size, as reducing --size is non-destructive.
Reducing the number of devices *is* destructive, so if you were to do
that, you would need to adjust the --array-size first.

So when you have prepared the contents of the array, use
  mdadm /dev/mdXXX --grow --size=750G

or whatever size you think is appropriate.

Then check that all your data is still accessible.  e.g. fsck your
filesystem.
If you are confident that the data is still accessible, you can continue
to --replace devices.
If not, you can
  mdadm /dev/mdXXX --grow --size=max

to restore the previous state, and then try to figure out what went
wrong.

NeilBrown


>
> So for number 4, if md0 is now small enough, will it accept a member that is
> smaller?  If so, I should beable to add the member to the array and issue
> --replace.
>
> Thanks.
>
> -- 
>  Microsoft has beaten Volkswagen's world record.  Volkswagen only created 22
>  million bugs.
> --
> 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: 832 bytes --]

  parent reply	other threads:[~2017-04-11  4:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-11  0:30 Shrinking an array Wakko Warner
2017-04-11  1:05 ` Adam Goryachev
2017-04-11  2:00   ` Wakko Warner
2017-04-11  4:33 ` NeilBrown [this message]
2017-04-11  6:58 ` Roman Mamedov

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=87fuhfwokr.fsf@notabene.neil.brown.name \
    --to=neilb@suse.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=wakko@animx.eu.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.