On 5/12/20 12:31 PM, Maksim Fomin wrote:
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, May 12, 2020 12:54 PM, Ondrej Kozina <okozina@xxxxxxxxxx> wrote:
There were basically two reasons for the increase in default LUKS2
metadata size IIRC:
1. As Milan pointed out online reencryption performs much better when
there's enough consecutive free space in LUKS2 keyslots area (the binary
area for keyslots material).
While testing we figured out with 16 MiB LUKS2 metadata we hit good
balance of getting good enough performance for reencryption and not
consuming too much free space on a drive so that it's not a big issue
for general use case and for users not interested in reencryption.
To get smaller metadata size you can format the device with:
cryptsetup luksFormat --offset 8192 and data offset (and LUKS2 metadata
size) will be at 4MiB exactly (similar to current LUKS1 default).
2. LUKS2 supports up to 32 keyslots. With 4 MiB keyslots area there
were not enough space to fill all keyslots.
In general I don't think 16MB is big issue nowadays and for special use
cases you can create smaller LUKS2 metadata. Even smaller than LUKS1.
Milan gave example here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932437#10
So I'd say 16 MiB is indeed recommended default LUKS2 metadata size in
most cases.
OK.
-------------------------------------------------------------------------------------
About extending existing LUKS2 metadata. Technically it's possible, but
currently you have to use reencryption for it since we have to reduce
data device size first before extending LUKS2 metadata.
cryptsetup reencrypt --reduce-device-size 4M /dev/sdx
(but do NOT forget to shrink residing filesystem/data first!)
By reducing data device by 4 MiBs we can extend LUKS2 metadata by same
value. In the process the data are shifted backwards towards tail of the
device.
In future we may add option to change LUKS2 metadata in-place w/o data
shifting (reencryption) but that would be feature that requires
cooperation with i.e. LVM2 or other volume management tools. If LVM2
could extends device by adding extents in head of LV, it would be
possible to simplify also online encryption etc.
Kind regards
O.
My question was not how to do it (obviously, one needs to move partition first), but why extra space for header may be needed. Is it for the case where users want (for some reason) often to do reencryption (not just for one time, but periodically)?
Yes, the better performance for reencryption is one reason. The other
that comes on my mind is that some current or future projects may want
to store some metadata in either LUKS2 unbound keyslot (binary area) or
in LUKS2 json format. For example systemd uses LUKS2 json area (token)
for systemd-homed metadata others may emerge.
Better plugin support is planned and it would also need some storage in
LUKS2 metadata.
O.
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
https://www.saout.de/mailman/listinfo/dm-crypt
