Jonas Meurer wrote: > i just did some benchmarking regarding the speed of luksOpen, as i have > the impression that it sometimes takes really long. possible reasons are: 1) every test for keyslot create new temporary device, it generates new device events and if udev rules are wrong, it will scan these devices (with udevsettle in 1.0.6 this was disaster) 2) it takes some time to check that key is wrong 3) keyfile direct read is not optimal I have already idea, that it could be done in one step (all 8 slot mapped at once, just create 8 segment dm-crypt device, just fiddling with initial IV sector for segments, then it is just reads of one device without additional uevents + ioctls). I added function to libdevmapper to easily setup crypt segment, but using that will make cryptsetup dependent on recent libdevmapper. But anyway, first try to run it with disabled udev, device nodes for cryptsetup are not created by udev, so test should work:-) > it is obvious that the time luksOpen takes is related to the keysize. > > but for some non-obvious reason it is neither proportional nor inverse > proportional related to size. > instead there seem to be keyfile sizes which cryptsetup is able to > process a lot faster than others. especially 128k seems to be a very > good size for key files. There is already patch to optimize direct reads, so probably it is time to test if that helps. Please can you create issue on project pages with the tests above to not forget about this? Should not be too much complicated to fix that. Milan --------------------------------------------------------------------- dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx For additional commands, e-mail: dm-crypt-help@xxxxxxxx
