[dm-crypt] expanding encrypted volume/growing the volume
arno at wagner.name
Wed Sep 10 11:42:13 CEST 2014
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
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
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
> > "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
> > 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 Wagner, Dr. sc. techn., Dipl. Inform., Email: arno at 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
More information about the dm-crypt