From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Thu, 11 Sep 2014 00:44:39 +0200 (CEST) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XRqct-0002Rm-Jq for dm-crypt@saout.de; Thu, 11 Sep 2014 00:44:35 +0200 Received: from c-24-14-20-249.hsd1.il.comcast.net ([24.14.20.249]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 11 Sep 2014 00:44:35 +0200 Received: from rnicholsNOSPAM by c-24-14-20-249.hsd1.il.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 11 Sep 2014 00:44:35 +0200 From: Robert Nichols Date: Wed, 10 Sep 2014 17:44:21 -0500 Message-ID: References: <20140909215203.GG26856@markov.biostat.ucsf.edu> <20140910033131.GD8520@markov.biostat.ucsf.edu> <20140910203650.GF8520@markov.biostat.ucsf.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In-Reply-To: <20140910203650.GF8520@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: dm-crypt@saout.de On 09/10/2014 03:36 PM, Ross Boylan wrote: > On Wed, Sep 10, 2014 at 08:25:07AM -0500, Robert Nichols wrote: >> The snapshot LV can increase its size only if you created it as thinly >> provisioned, and even then it can grab extents only within the LV that >> you set up as a "thin pool" LV. The space within that thin pool LV is >> not "free" for the purposes of creating a new LV. Creating a new LV >> with "--extents 100%FREE" will not affect expansion of your snapshot >> LVs. >> > > Good; I didn't do thin provisioning. > > Game Plan (for IMAP server and its spool): > ## Verify that backups are OK > > ## randomize free space in LVM volume group turtle > lvcreate -l 100%FREE -n tozero turtle > cryptsetup open --type plain -d /dev/urandom /dev/turtle/tozero zero_crypt > dd_rescue -w /dev/zero /dev/mapper/zero_crypt > # free space ~ 100G--likely to take awhile. Hours? days? > # if it's really slow I could allocate 2 LVs, one of which is the size > # I need ~50G, and the other of which is filler. randomize the 50G; > # free the space, and extend my volume. > cryptsetup remove zero_crypt > lvremove turtle/zero > > ## make encrypted spot to backup recent files > # /usr/local/backup is not encrypted. Assume I create a small encrypted volume > # and mount it at /usr/local/backup/crypt > > ## shutdown server > > ## backup current server state > # do manual backup of selected server state > # If possible make a backup of the directories the usual way. > # Otherwise, as root > cd /usr/local/backup/crypt > # snapshots at 00:10 daily. Assume current day has not > # been backed up yet. > tar cjf cyrspool-recent.tar.bz2 --after-date 'Sep 9 00:09 -0800' /var/spool/cyrus > > ## take directory offline > umount /var/spool/cyrus > cryptsetup luksClose cyrspool_crypt > # maybe close snapshot of turtle/cyrspool before extending? > > ## Actually grow things > lvextend -L +20G turtle/cyrspool > cryptsetup --key-file xxx luksOpen /dev/turtle/cyrspool cyrspool_crypt > resize_reiserfs /dev/mapper/cryspool_crypt > reiserfsck /dev/mapper/cyrspool_crypt > mount /var/spool/cyrus > > ## restart IMAP server I haven't gone over that with the proverbial fine-tooth comb, but it looks reasonable. I would expect the initializing of 100GB to take on the order of 20 minutes (100GB at ~85MB/sec -- a decent CPU and internal disk should sustain that easily). Yes, I would merge the snapshot back into the base volume and close the snapshot before extending the filesystem. Otherwise, the enlarged filesystem structure will exist only in the snapshot. I suppose an alternative would be to merge the current snapshot, start a new snapshot, and the enlarge the filesystem. If anything went wrong during the resizing, you could just discard the snapshot and be right back where you were with the filesystem. Merge that snapshot once you've determined that all went well. -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it.