cryptsetup-reencrypt: Specifying device size

Hi list,

I'm wondering how safe it is to specify a device size when re-encrypting a block device using cryptsetup-reencrypt. In particular I would like to know if specifying a size smaller than the underlying block device might actually corrupt data?

The man page mentions some warnings in regards to this option. In our use case the underlying block device is ~ 100G, while only 11G are actually used by filesystems on top of the block device. To speed things up we were thinking about a device size, e.g. something like 16G, so not the whole device needs to be re-encrypted.

I'm not familiar enough with the LUKS internals, but I'm pretty sure that it is not filesystem aware, so it will only reencrypt the first 16GB of the device, while LVM and any filesystems may actually put data anywhere on the device.

So am I right in assuming that providing a device size smaller than the actual block device size might lead to data corruption or is it safe to use it in the way described above?

Best regards,
Karol Babioch

It may corrupt data just if used wrongly.

1) if you have already LUKS there (and you are not increasing header size) the --device-size <X> says to perform reencryption only for <X> data size.

If <X> is too small, it will keep part of data not reencrypted, IOW destroys that not reencrypted part practically.

2) If adding new LUKS encryption
the --reduce-device-size <X> will shift data to create <X> sized space for header and keyslots (IOW always destroys <X> area in the end of device).

(Be sure which units you are using, it can do both - SI or 1024 based, see man page).

If there is already LUKS you should be ok this way. Anyway, better test it first on some other disk.

(We had installation which used similar approach with layered LVM, it had small LV which was reencrypted and then resized to cover full disk.)

You do not need LUKS internals at all. For LVM you can use pvmove to "defragment" area, but it is very tricky sometimes (if extents are moved on the same PV device).

In LVM use "pvs -o+devices" to quickly check which area LVM uses (number in bracket is starting extent for the given segment, it should be 0 if it is really in the beginning of PV).

It should be problematic only if it is smaller than really used area. (It is nothing more than just stop reencryption after specified size.)

But anyway, I would suggest to reencrypt whole 100G, it is not
so big and you will have wiped all resident plaintext data in unused area this way.

Milan

Milan needs to answer that. Let me just reming you that doing an operation like that without current backup is asking for trouble up to and including loss of all data.

Arno

Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: [email protected]
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

I hope you are NOT saying that you have a filesystem larger than 16G there but 'du" reports that only 11G are used. If that were the case, then reencrypting just 16G would mean guaranteed destruction of the filesystem.

You can test what would happen quite easily. Use "cryptsetup resize ..." to _temporarily_ limit the active mapping to 16GB. Then see if "fsck" still reports that all filesystem are OK. If so, then you can safely reencrypt just the first 16GB. If "fsck" complains about any filesystems, just close the container ("cryptsetup remove ...") and no damage is done. LUKS does not permanently record the size of the container; it will always default to the size of the underlying device or partition.

Bob Nichols     "NOSPAM" is really part of my email address.
                Do NOT delete it.

Milan gave quite an extensive answer to your questions.

One thing I want to add, the LVM metadata is stored 2k from the start of the device - if you only use 1 metadata-copy that is (which is default).

As Milan said, make sure which extents are actually ocupied. As others
mentioned: Backup and then dry run with a mapping of enforced reduced size to see if the possible result is useable at all.

Regards

-Sven