Re: [dm-crypt] expanding encrypted volume/growing the volume

From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] expanding encrypted volume/growing the volume
Date: Wed, 10 Sep 2014 07:16:10 +0200	[thread overview]
Message-ID: <20140910051610.GA6059@tansi.org> (raw)
In-Reply-To: <20140910043024.GA3916@markov.biostat.ucsf.edu>

On Wed, Sep 10, 2014 at 06:30:24 CEST, Ross Boylan wrote:
> A little more on resizing on the bottom, with related excerpts above it.
[...]
> At least one piece of advice on the internet does luksClose, luksOpen 
> AND cryptsetup resize:
> http://www.xbsd.nl/2012/03/resize-an-encrypted-lvm-logical-volume.html

That one is broken. Or rather the "resize" does nothing to
the LUKS container. It may just be there for the --verbose.
Really, there is no "partition size" field anywhere in the 
LUKS header and it is not needed.

A brief look into the man-page shows what "resize" does:

 resize <name>

    Resizes an active mapping <name>.
    If --size (in sectors) is not specified, the size of the under‐
    lying  block  device is used. Note that this does not change the
    raw device geometry, it just changes how many sectors of the raw
    device are represented in the mapped device.

As to my other comments, I see now that you left out one very 
critical piece of information: You want to do this _online_.
(Or I read over it. If so, sorry.) That is generally not a 
good idea, but that is indeed one of the scenarios where you 
would need "cryptsetup resize". (But not after a luksOpen.
luksOpen reads the device-size from the kernel anyways.)

You would need to extend the partition first, make the kernel 
aware of the new size (I gather lvextend does that, personally I 
stay away from LVM, far too complicated...), call 
"cryptsetup resize <device>" and then extend the filesystem 
in the LUKS container. If all of that works, good. If anything 
goes wrong, I hope you refreshed that backup and have the time 
to restore from it. 

Generally, in a situation where you have low downtime needs, 
you should have a second identical machine with automatic 
fail-over anyways. There you can take down one machine,
make the changes offline, test them, bring it back up
and then fail-over to it. Repeat with the second one.

If you  do not have low downdime needs, do this offline,
as the risk of doing some real damage is lower.

Arno

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier