From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gmazyland@gmail.com>
Received: from mail-ea0-x229.google.com (mail-ea0-x229.google.com
 [IPv6:2a00:1450:4013:c01::229])
 (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
 (No client certificate requested)
 by mail.saout.de (Postfix) with ESMTPS
 for <dm-crypt@saout.de>; Thu, 13 Mar 2014 07:34:33 +0100 (CET)
Received: by mail-ea0-f169.google.com with SMTP id h14so267379eaj.28
 for <dm-crypt@saout.de>; Wed, 12 Mar 2014 23:34:32 -0700 (PDT)
Received: from [192.168.2.17] (56.157.broadband5.iol.cz. [88.100.157.56])
 by mx.google.com with ESMTPSA id q44sm4707486eez.1.2014.03.12.23.34.31
 for <dm-crypt@saout.de>
 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
 Wed, 12 Mar 2014 23:34:31 -0700 (PDT)
Message-ID: <53215176.7000103@gmail.com>
Date: Thu, 13 Mar 2014 07:34:30 +0100
From: Milan Broz <gmazyland@gmail.com>
MIME-Version: 1.0
References: <loom.20140312T000413-75@post.gmane.org>
 <20140312005412.GA25009@tansi.org> <loom.20140312T222042-236@post.gmane.org>
 <20140313002938.GA31353@citd.de> <20140313013154.GA5434@tansi.org>
In-Reply-To: <20140313013154.GA5434@tansi.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [dm-crypt] cryptsetup-reencode: LUKS-${UUID}.new is too small
List-Id: <dm-crypt.saout.de>
List-Unsubscribe: <http://www.saout.de/mailman/options/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=unsubscribe>
List-Archive: <http://www.saout.de/pipermail/dm-crypt/>
List-Post: <mailto:dm-crypt@saout.de>
List-Help: <mailto:dm-crypt-request@saout.de?subject=help>
List-Subscribe: <http://www.saout.de/mailman/listinfo/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=subscribe>
To: dm-crypt@saout.de

On 03/13/2014 02:31 AM, Arno Wagner wrote:
>> If you imagine disc sectors/blocks as a stack, growing/shrinking 
>> adds/removes(or frees) blocks at the top.
> 
> That was my first take also, but the manpage for cryptsetup-
> reencrypt option --reduce-device-size says 
> 
> "This means that last sectors on the original device will be 
> lost, ciphertext data will be effectively shifted by specified 
> number of sectors."

Yes, with --reduce-device-size it reencrypts "backwards" with optional
data shift.

If your fs supports shrinking and you want to be safe, just shrink fs
of twice size of needed LUKS extension (e.g. 8MB and then use 4MB
in reduce size option) and after reencryption just resize to full device.

Or with LVM just enlarge LV by 4MB (but this can fragment LV and
you need free space).

I described some crazy reencrypt operations here
http://asalor.blogspot.cz/2012/08/re-encryption-of-luks-device-cryptsetup.html

but as was already said: it is dangerous, backups are mandatory.

Milan