DragonFlyBSD Lands "Next-Gen" Disk Encryption Code

Summary

It's been a while since having any exciting feature development to talk about with DragonFlyBSD but merged this past week was dm_target_crypt_ng, a next-generation implementation of their DM-crypt code for disk encryption. DragonFlyBSD developer Michael Neumann re-engineered the DM-crypt code for this BSD operating system as this transparent disk encryption implementation compatible with Linux's dm-crypt. Michael Neumann explained in the initial commit landing this next-generation code: "dm_target_crypt_ng - Add next-generation implementation * No longer use opencrypto or cryptodev. These were asynchronous and caused a lot (!) of complications to the code. * Instead, use our own set of crypto ciphers implemented in crypto_cipher.{c,h}, which is a simplified API to use symmetric block ciphers. It mostly calls out to the actual crypto algorithm implementations contained under sys/crypto. * Interactivity is greatly improved! When running "blogbench" with the old dm_target_crypt module, "blogbench" basically "freezes" the system at around 400 number blogs (Nb). The mouse cursor continuously freezes for about 1 second. While the computer becomes slower when running dm_target_crypt_ng, no lag of mouse can be observed. The final "blogbench" performance result stays about the same. For example: # dm_target_crypt (old) Final score for writes: 2136 Final score for reads : 200584 # dm_target_crypt_ng (new) Final score for writes: 2265 Final score for reads : 203668 * BIOs are processed by two worker pools, each having a set of threads bound to a particular CPU. Read requests need to be decrypted, while write requests need to be encrypted. Having a separate worker pool for read and write requests should provide more fairness. Requests are scheduled to the workers using round-robin, and "struct bio" is used to chain "requests" to be processed by worker threads. Read workers need no further memory to be allocated in order to decrypt the blocks. The write workers use a shared mpip...