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

[Arno Wagner <arno@wagner.name>]

On Wed, Sep 10, 2014 at 10:16:39 CEST, Ross Boylan wrote:
> 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.  

Using resize _without_ parameter directly after luksOpen is
meaningless, as it will not change anything. That is what the
referenced example does. As I said, the resize may only be there
for what it says because of --verbose.

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

There is no need to resize to the default size. If, for any 
reason, you want another size, then there may be, but that 
would be calling resize _with_ size parameter.

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

I still have trouble with that. For resizing simple volumes,
parted works just fine. I think it adds significant complexity,
while makeing a rare operation a bit easier. That is not in
line with KISS. But opinions on this issue differ. I am an 
old-school CS person, I want KISS and reliability over
everything else except in special situations. The younger
crowd disagrees, possibly because computers have gotten
so much more reliable and most of them are missing a real
disaster-experience.

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

Personally, I grow RAID1 by simply kicking a component, resizing 
that by re-creation and then making a degraded volume on that.
Copy data, and repeat with other RAID components. (As I have
important stuff on 3-way RAID1, this is far less rispy than it
may sound. With backup it is also fine.) And Yes, I do RAID
on paritions, after all that is one of the major advantages
of software-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?  

The second. The first option is usually overkill. "Donwntime to the
storage=unit being worked on."

> Obviously in some cases umounting
> the device is only possible if the OS is down.

One reason to have a relatively small root partition and to
not have anything except the system on it. 

But anyways, we seem to be getting somewhere. Please make that
current backup nonetheless and make a header backup of the LUKS 
container in addition, it is far to easy to break the header.

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