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? > > > 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. You seem to be overlooking my initial statement that I planned to "grow the encrypted container [bad phrasing] and then the file system on it". I'm aware that the file system must be resized. > Filesystems do nto grow by themselves. You could > just zero the space behind 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. I have backups, though not completely current--they happen outside of my control. I do not have enough space to create a whole new volume of the desired size. And a copy would be quite slow. The most delicate operation involves a mail spool. I suppose I should first shut down the server, backup the key files, and backup everything that has changed since the previous snapshot (I control the snapshots). I'm not sure what you mean by "the space behind the file system". If I've extended the LV, I know where the new space on the LV is, approximately. But I doubt I can determine it exactly. > > > 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? > 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. That's why I'm asking. I think I was misled by an experience with raid sofware, which has metadata at or near the end of the device (mdadm with 0.90 superblock format). I thought there was some metadata the crypto system put in its containers after the LUKS container; http://wiki.cryptsetup.googlecode.com/git/LUKS-standard/on-disk-format.pdf says not. And you just said even the metadata in the LUKS container does not record the device size. 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. Ross > 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. I have some 20G LV's, and so would prefer to avoid the recreation; the backup is clearly essential. > > > 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
