The progress function remained silent unless the speed was higher
than minimal delta for double type in MiB/s. That could confuse
users that progress got stucked, but it in fact it was only slow.
Now wipe and reencryption progess functions can report speeds
in B/s up to GiB/s.
When resuming reencryption operation (both LUKS2 and legacy offline
code) speeds were incorectly calculated from whole progress including
range already reencrypted in previous runs. Now we track speed only
for currently running session.
It also fixes minor regression where we return backing file
for partition on top of loop device when prompting for passphrase.
Partition on loop has different major number so it should not be
considered loop device at all.
Currently hard memory limit is 1 GiB. Soft limit is
1/4 of system memory.
Note that --hotzone-size cryptsetup parameter can only further
lower hard and soft memory limit on hotzone size and not bypass
it.
It may be useful to activate device right after LUKS2 encryption
is initialized:
device is ready to use immediately even if data encryption runs in
the background for a long time
It simplifies encryption initialization during reboot.
The check for enough space before moving keyslots data did not expect real
detached header size to be less than aligned LUKS1 header size.
Also if detached header is placed in regular file we can grow so that
moved keyslots area fit the file.
Fixes#445.
This regression was introduced in cryptsetup 2.0.0 release
with refactoring "Enter passphrase for (dev)" prompt.
With cryptsetup 1.7.5, "cryptsetup open /dev/loop0" printed
following prompt:
"Enter passphrase for /path/to/loop/backing_file:"
Whereas cryptsetup 2.0.0 and on printed following one:
"Enter passphrase for /dev/loop:"
Reported in https://bugzilla.redhat.com/show_bug.cgi?id=1726287
Fixes: 39698fa6b7 ("Remove terminal input from libcryptsetup API calls.")
Fixes: c80acbe4c8 ("Add back "Passphrase for (dev):" prompt.")
Fixes: 5171f65c05 ("tests only: Return back password retry support for luksOpen.")
If device properly exposes optimal io size, let's align
reencryption hotzone to it. Otherwise device-mapper driver
complaints about misaligned tables and reencryption performance
is not optimal.
