DM-Crypt Archive on lore.kernel.org
 help / color / mirror / Atom feed
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 01:50:38 +0200	[thread overview]
Message-ID: <20140909235037.GA2652@tansi.org> (raw)
In-Reply-To: <20140909215203.GG26856@markov.biostat.ucsf.edu>

On Tue, Sep 09, 2014 at 23:52:03 CEST, Ross Boylan wrote:
> My system uses LVM, with LUKS encryption on top of individual logical
> volumes.  The volume group has some free space, and I would like to
> extend the volume and then grow the encrypted container and then the
> file system on it.

You cannot "grow the encrypted container". A LUKS mapping has no fixed
size associated with it. It merely takes the size of the underlying
raw container as its size. So if you resize the raw container, the
LUKS container changes size automatically on re-mapping.
 
> When expanding I'll use free space that I don't believe has ever been
> zeroed or random filled.  It's possible it was used for a file system
> at some point.
> 
> Is that much of a concern?  The FAQ advises wipeing it, though the
> only explicit reasons seem not much of a concern for space in a volume
> group (but later there are references to attacks available if the
> attacker can determine which sectors are unused).  As far as I know
> there is no way to access the unused area of the volume group (well,
> except for mapping all physical device sectors in use and operating on
> the remainder after somehow figuring out where metadata is kept), and
> attempting to do so seems hazardous.  It seems particularly hazardous
> because there are active snapshots, and it seems possible they grab
> freespace dynamically.

Youa re overlooking one thing: If you resize the raw container and
re-map LUKS, you will still have the old filesystem size in the
LUKS container. Filesystems do nto grow by themselves. You could
just zero the space behinf the filesystem. If you get it wrong,
you may kill the filesystem though. But resizing a partition or
filesystem is not something you should do without a full, verified
backup anyways.

> Is
> cryptsetup resize /dev/VG/LV
> the right way to expand the container once the LV is extended?  

No. cryptsetup resize resizes the mapping temporarily to something
else than the underlying raw container size.

> Are there any things I should look out for in the whole process?  Do I
> need to reboot or remount anywhere along the way for changes to take
> effect?  The filesystems are ext3 and reiser.

Aehm, you need to umount and unmap everything before doing this?
You need a full, verified backup of _all_ data?

Seriously, I do not think you understand what you want to do 
enough to do it safely. Better make that full backup and 
recreate the raw container in question with the new size,
make a new LUKS container out of it and put a new filesystem
in it after zero-wiping it. 

> The software on the system is quite old, Debian Lenny + some
> backports.  cryptsetup is at 1.0.6 (Debian version 2:1.0.6-7) and the
> kernel is 2.6.32 (which is a backport).

That should not matter.

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

  reply	other threads:[~2014-09-09 23:50 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-09 21:52 [dm-crypt] expanding encrypted volume/growing the volume Ross Boylan
2014-09-09 23:50 ` Arno Wagner [this message]
2014-09-10  3:23   ` Ross Boylan
2014-09-10  4:30     ` Ross Boylan
2014-09-10  5:16       ` Arno Wagner
2014-09-10  8:16         ` Ross Boylan
2014-09-10  9:42           ` Arno Wagner
2014-09-10  1:59 ` Robert Nichols
2014-09-10  3:31   ` Ross Boylan
2014-09-10 13:25     ` Robert Nichols
2014-09-10 20:36       ` Ross Boylan
2014-09-10 22:44         ` Robert Nichols
2014-09-10 22:52           ` Robert Nichols
2014-09-10 23:47             ` Ross Boylan
2014-09-11  4:00               ` Robert Nichols

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=20140909235037.GA2652@tansi.org \
    --to=arno@wagner.name \
    --cc=dm-crypt@saout.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox