Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#31230 - [libcryptsetup] dm-crypt unlocking with systemd-cryptsetup is a lot slower than with the old scripts
Attached to Project:
Arch Linux
Opened by Heiko Baums (cyberpatrol) - Tuesday, 21 August 2012, 21:21 GMT
Last edited by Dave Reisner (falconindy) - Saturday, 20 October 2012, 16:56 GMT
Opened by Heiko Baums (cyberpatrol) - Tuesday, 21 August 2012, 21:21 GMT
Last edited by Dave Reisner (falconindy) - Saturday, 20 October 2012, 16:56 GMT
|
DetailsDescription:
If the harddisk is encrypted with dm-crypt/LUKS the unlocking of the containers done by /etc/rc.d/functions at boot time is a lot slower with the new syntax in /etc/crypttab (systemd-cryptsetup) than with the old syntax (the old scripts). I have 2 encrypted partitions which are unlocked at boot time by initscripts. The keys are written rawly on a USB stick and have to be read rawly. (See: do_unlock_legacy() -> /dev*) -> *)) With the new syntax it takes between 42 and 43 seconds to read the 2 keys from the USB stick and to unlock both partitions. Every single partition takes about 21 seconds. With the old syntax it takes between 11 and 13 seconds to read the 2 keys from the USB stick and to unlock both partitions. Every single partition takes about 6 seconds. This long delay with the new syntax (systemd-cryptsetup) is totally unacceptable and needs to be fixed or removed in favor of the old syntax and scripts. This is the old syntax in /etc/crypttab: home /dev/sdaX /dev/usbstick:12345678:1024 This is the new syntax in /etc/crypttab: home /dev/sdaX /dev/usbstick keyfile-size=1024,keyfile-offset=12345678 |
This task depends upon
Closed by Dave Reisner (falconindy)
Saturday, 20 October 2012, 16:56 GMT
Reason for closing: Fixed
Additional comments about closing: testing/cryptsetup 1.5.1-1
Saturday, 20 October 2012, 16:56 GMT
Reason for closing: Fixed
Additional comments about closing: testing/cryptsetup 1.5.1-1
essentially, each of columns in order from /etc/crypttab. It'll probably be fairly noisy. You can pass the -o flag with a filename to get the output logged to a file, but I assume you'd want to look at it as it goes by to see if there's some sort of crazy loop, or some syscall that it's hanging on.
FS#31240is fixed.My guess is that libcryptsetup does something crazy, but a strace would tell us for certain (hopefully).
Notice how the legacy stuff does dd with "bs=1". If I understand correctly, that's about as inefficient as it is possible to get, so I'm rather confused how we managed to be slower than that...
Nothing else that I can test myself here.
# time uncrypt-initscripts
unlock swap
unlock home
real 0m13.498s
user 0m12.942s
sys 0m0.100s
# time uncrypt-systemd
unlock swap
unlock home
real 0m45.571s
user 0m15.806s
sys 0m28.248s
uncrypt-* are scripts that do the same as the corresponding commands in /etc/rc.d/functions but without all those cases and variables.
Doing an strace of systemd-cryptsetup is almost impossible if not totally impossible. After 5 minutes of seeing a lot of "read..." I cancelled it.
Is it possible that systemd-cryptsetup first reads the whole keyfile device, which would be a total 4 GB stick, and a slow one, in my case, and cuts the relevant part out of this whole output afterwards? Just a wild guess. If this is the case then this needs to be fixed to the way dd reads it.
I mean, bs=512 would be faster, but what if the keyfile size is just 1011? Are then only the 1011 bytes read or would it read 1024 bytes? With bs=1 I'm sure that it will only read the 1011 bytes.
bs=$keyfile_size count=1
Anyways, the issue is that cryptsetup "seeks" to the keyfile_offset 1 byte at a time, which means a syscall for every byte. It can't actually use lseek because there's no guarantee of seekable input (cryptsetup can read the file from stdin which could be a pipe). We never saw this issue with initscripts because we guaranteed a 0 byte offset by extracting the key from the containing file to its own temporary file.
I've put together a patch which reads up to 4k at a time, and it's much faster. I'll submit it upstream after I do the same optimization for reading the actual key.
If this is really faster and working as expected, I don't mind.
Is it really necessary to seek to the keyfile_offset? Is dd doing this the same way? If yes, wouldn't it be better then to seek the same way as reading the keyfile itself, with something like bs=$keyfile-offset-1 count=1?
No key available with this passphrase.
So bs=1 count=$keyfile-size is necessary.
/usr/lib/systemd/systemd-cryptsetup attach "name" "device" "keyfile"
These are the results:
# time uncrypt-file
unlock swap
unlock home
real 0m14.486s
user 0m13.932s
sys 0m0.067s
# time uncrypt-file
unlock swap
unlock home
real 0m15.066s
user 0m14.516s
sys 0m0.057s
So the main problem is how the keyfile is read by systemd-cryptsetup. But unlocking the container by systemd-cryptsetup is also slightly slower, even if it's only 2 or 3 seconds.
You're on your own to figure out those "2-3 seconds". I'm only willing to fix the obvious problem here. Based on your constant abuse of Arch developers, I think you should show some gratitude that I'm even going out of my way to do this. It's because of everyone but yourself that this option even exists with systemd, and yet I suspect you're one of the extraordinarily few users of it.
http://code.google.com/p/cryptsetup/issues/detail?id=135
And this option (reading a keyfile raw from a device) doesn't exist in the initscripts (/etc/rc.d/functions) just because of me, but because it already existed in the encrypt hook long before and was documented in the wiki. And if you change the initscripts and use different mechanisms and tools, those changes and tools simply must cover every use case which has been covered before. Regressions in such an important part of the system is a no-go, regardless of how many people are using it.
Like I said on the mailing list, even if Tom was ranting about that, we're not talking about some fancy stuff like a GTK theme, we're talking about something very serious.
http://code.google.com/p/cryptsetup/source/detail?r=961682aa6b228
I'll leave it up to the cryptsetup maintainer to figure out if they want to backport this or just wait for the release. Doesn't bother me either way.