From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <ross@biostat.ucsf.edu>
Received: from biostat.ucsf.edu (upstrm185.psg-ucsf.org [38.99.193.74])
 (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mail.server123.net (Postfix) with ESMTPS
 for <dm-crypt@saout.de>; Wed, 10 Sep 2014 10:16:42 +0200 (CEST)
Date: Wed, 10 Sep 2014 01:16:39 -0700
From: Ross Boylan <ross@biostat.ucsf.edu>
Message-ID: <20140910081639.GE8520@markov.biostat.ucsf.edu>
References: <20140909215203.GG26856@markov.biostat.ucsf.edu>
 <20140909235037.GA2652@tansi.org>
 <20140910032337.GC8520@markov.biostat.ucsf.edu>
 <20140910043024.GA3916@markov.biostat.ucsf.edu>
 <20140910051610.GA6059@tansi.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20140910051610.GA6059@tansi.org>
Subject: Re: [dm-crypt] expanding encrypted volume/growing the volume
List-Id: <dm-crypt.saout.de>
List-Unsubscribe: <http://www.saout.de/mailman/options/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=unsubscribe>
List-Archive: <http://www.saout.de/pipermail/dm-crypt/>
List-Post: <mailto:dm-crypt@saout.de>
List-Help: <mailto:dm-crypt-request@saout.de?subject=help>
List-Subscribe: <http://www.saout.de/mailman/listinfo/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=subscribe>
To: Arno Wagner <arno@wagner.name>
Cc: dm-crypt@saout.de

On Wed, Sep 10, 2014 at 07:16:10AM +0200, Arno Wagner wrote:
> 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.)

The parenthetical remark sounds as if it's saying not to use
cryptsetup resize after luksOpen, but I don't think that's the
intended meaning since without luksOpen (or cryptsetup create if not
using LUKS) there is nothing to resize.  So is it a restatement of the
fact that if the sequence is lvextend and then luksOpen, there's no
need to resize (unless one is trying to shrink after having shrunk the
filesystem)?

> 
> 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 

LVM certainly adds another layer, but it's really handy for growing
volumes.

> "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.
> 

The whole thing is sitting on top of RAID-1 and so I could take one
part of it offline.  But that raises a bunch of other issues.  When I
have more time, I will eventually want to grow the RAID.

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

By offline do you mean shutting down the whole OS and using, e.g.,
Knoppix to fiddle with the disks, or just  umounting the decrypted
device and then doing a luksClose?  Obviously in some cases umounting
the device is only possible if the OS is down.

Ross