[dm-crypt] Does luksFormat write the full size of the device?

[dm-crypt] Does luksFormat write the full size of the device?

[Charles Cazabon]

Hi,

I'm currently initializing a fairly large LUKS crypt device, about 33TiB.
I've done this before, but not for quite a while, so I can't remember how long
it normally takes.  My current cryptsetup invocation has been running for
about 24 hours, taking 100% of one CPU core for that entire time.  If there's
I/O happening, iostat isn't showing it.

If `cryptsetup luksFormat` has to write the entire contents of the underlying
block device, then this length of time is reasonable - but I don't recall if
it has to do that.

Is this long runtime normal for initialization of a device of this size?

System is Debian Wheezy with a mainline 4.6.2 kernel, cryptsetup 1.4.3 from
the normal Debian package.

Thanks,

Charles
-- 
------------------------------------------------------------------
Charles Cazabon                              <charlesc@pyropus.ca>
Software, consulting, and services available at http://pyropus.ca/
------------------------------------------------------------------

Re: [dm-crypt] Does luksFormat write the full size of the device?

[Milan Broz]

On 06/26/2016 05:39 AM, Charles Cazabon wrote:
> Hi,
> 
> I'm currently initializing a fairly large LUKS crypt device, about 33TiB.
> I've done this before, but not for quite a while, so I can't remember how long
> it normally takes.  My current cryptsetup invocation has been running for
> about 24 hours, taking 100% of one CPU core for that entire time.  If there's
> I/O happening, iostat isn't showing it.
> 
> If `cryptsetup luksFormat` has to write the entire contents of the underlying
> block device, then this length of time is reasonable - but I don't recall if
> it has to do that.

No, format doesn't write the whole device.

Can you please post output of running commant with added --debug switch?
(Just up to point it starts to eat CPU cycles.)

(I think it loops in PBKDF2 benchmark, I have seen some unexpected breakage
here with recent kernel, but without debug log it is just guess.)

> Is this long runtime normal for initialization of a device of this size?

No. If the default iteration time (1 or 2 seconds) is not changes, format should
be done in max 4-5 seconds.

Thanks,
Milan

Re: [dm-crypt] Does luksFormat write the full size of the device?

[Charles Cazabon]

Milan Broz <gmazyland@gmail.com> wrote:
> On 06/26/2016 05:39 AM, Charles Cazabon wrote:
> 
> No, format doesn't write the whole device.

Ok, thanks.  That explains why I don't remember it taking this long before.

> Can you please post output of running commant with added --debug switch?

Sure:

---------------------------
# cryptsetup --debug luksFormat /dev/md0
# cryptsetup 1.4.3 processing "cryptsetup --debug luksFormat /dev/md0"
# Running command luksFormat.
# Locking memory.

WARNING!
========
This will overwrite data on /dev/md0 irrevocably.

Are you sure? (Type uppercase yes): YES
# Allocating crypt device /dev/md0 context.
# Trying to open and read device /dev/md0.
# Initialising device-mapper backend, UDEV is enabled.
# Detected dm-crypt version 1.14.1, dm-ioctl version 4.34.0.
# Timeout set to 0 miliseconds.
# Iteration time set to 1000 miliseconds.
# Interactive passphrase entry requested.
Enter LUKS passphrase: 
Verify passphrase: 
# Formatting device /dev/md0 as type LUKS1.
# Crypto backend (gcrypt 1.5.0) initialized.
# Topology: IO (524288/3145728), offset = 0; Required alignment is 3145728
# bytes.
# Generating LUKS header version 1 using hash sha1, aes, cbc-essiv:sha256, MK
# 32 bytes
^C
---------------------------

I aborted it after a couple of minutes this time.

I've compiled 1.7.2 from the source tarball, and it does the same thing,
spinning on one CPU.  One difference is that it doesn't seem to respond to a
ctrl-C; it's still running after trying to abort it.  I haven't tried to kill
it with other signals yet.  Here's the output from it:

---------------------------
# ~xxxxxxx/software/cryptsetup-1.7.2/src/.libs/cryptsetup --debug luksFormat /dev/md0
# cryptsetup 1.7.2 processing
# "/home/xxxxxxx/software/cryptsetup-1.7.2/src/.libs/cryptsetup --debug luksFormat /dev/md0"
# Running command luksFormat.
# Locking memory.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.

WARNING!
========
This will overwrite data on /dev/md0 irrevocably.

Are you sure? (Type uppercase yes): YES
# Allocating crypt device /dev/md0 context.
# Trying to open and read device /dev/md0.
# Initialising device-mapper backend, UDEV is enabled.
# Detected dm-crypt version 1.14.1, dm-ioctl version 4.34.0.
# Timeout set to 0 miliseconds.
# Iteration time set to 2000 miliseconds.
# Interactive passphrase entry requested.
Enter passphrase: 
Verify passphrase: 
# Formatting device /dev/md0 as type LUKS1.
# Crypto backend (gcrypt 1.5.0) initialized.
# Topology: IO (524288/3145728), offset = 0; Required alignment is 3145728
# bytes.
# Generating LUKS header version 1 using hash sha256, aes, xts-plain64, MK 32
# bytes
---------------------------


> > Is this long runtime normal for initialization of a device of this size?
> 
> No. If the default iteration time (1 or 2 seconds) is not changes, format
> should be done in max 4-5 seconds.

Ok, then something is definitely still wrong here.  I'm guessing the newish
kernel is related?

Thanks,

Charles
-- 
------------------------------------------------------------------
Charles Cazabon                              <charlesc@pyropus.ca>
Software, consulting, and services available at http://pyropus.ca/
------------------------------------------------------------------