From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ; Wed, 10 Sep 2014 06:30:26 +0200 (CEST) Date: Tue, 9 Sep 2014 21:30:24 -0700 From: Ross Boylan Message-ID: <20140910043024.GA3916@markov.biostat.ucsf.edu> References: <20140909215203.GG26856@markov.biostat.ucsf.edu> <20140909235037.GA2652@tansi.org> <20140910032337.GC8520@markov.biostat.ucsf.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140910032337.GC8520@markov.biostat.ucsf.edu> Subject: Re: [dm-crypt] expanding encrypted volume/growing the volume List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ross Boylan Cc: dm-crypt@saout.de, Arno Wagner A little more on resizing on the bottom, with related excerpts above it. On Tue, Sep 09, 2014 at 08:23:37PM -0700, Ross Boylan wrote: > Thanks for your response. Questions/comments below. > On Wed, Sep 10, 2014 at 01:50:38AM +0200, Arno Wagner wrote: > > 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. > > I was wondering if "encrypted container" was the right phrase; it > seems not. I definitely did not mean the LUKS container. > > I'll use this: > /dev/VG/LV = raw device > /dev/mapper/LV_crypt = decrypted device (cryptsetup luksOpen /dev/VG/LV LV_crypt) > > After lvextending LV it would then be > cryptsetup resize LV_crypt > with resize by default using the size of the underlying raw device. > > Are you saying that there is no need to cryptsetup resize? And that I > must bring down (in the cryptsetup luksClose sense) and up (cryptsetup > luksOpen) LV_crypt to make it full size? .... > > > 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. > > I see now that should have been LV_crypt, not /dev/VG/LV. > > > > > 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? > Even if the filesystem supports online resize? ... > > So here's what I'm thinking of doing, all while the filesystem is live.: > #backup > # I was thinking of zeroing here, without knowing how to do it safely. > lvextend -L +20G VG/LV > # zero here? how to do it safely? > cryptsetup resize LV_crypt # unnecessary? insufficient? > resize_reiserfs /dev/mapper/LV_crypt > > If crypsetup resize does not do what I need, instead luksClose, > lvextend, luksOpen, resize_reiserfs. Obviously the filesystem would > not be live during the operation, and surrounding umount and mout > would be needed. > 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 Ross