Does luksFormat write the full size of the device?

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                              <[email protected]>
Software, consulting, and services available at http://pyropus.ca/
------------------------------------------------------------------

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.)

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

Thanks,
Milan

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

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
---------------------------

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

Thanks,

Charles

------------------------------------------------------------------
Charles Cazabon                              <[email protected]>
Software, consulting, and services available at http://pyropus.ca/
------------------------------------------------------------------