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 > filesystem)? 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 > volumes. 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 disaster-experience. > > "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 of software-RAID. > > 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 -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
