Support for passing no_read/write_workqueue to cryptsetup

[refi64]

A while back, Cloudflare did a blog post where they detailed some changes they made to improve their performance under LUKS, involving two new cryptsetup flags, no_read_workqueue and no_write_workqueue. I figured I'm give them a try...but, as it turns out, Stratis doesn't have any way of passing custom values to cryptsetup. For testing purposes, I added the new flags to libcryptsetup-rs (I'm aware this probably won't build on older libcryptsetup-rs versions, but for testing, this was fine) and then unconditionally activated cryptsetup with the relevant flags. After some pain in getting it installed (tried to build the RPM but didn't feel like figuring out how to get the cryptsetup-rs changes into mockbuild), I can confirm it any optionsdoes work, though I have no idea if it's faster or not yet.

Regardless, it would be nice to have this as an option. This brings me to the problem I realized as I was adding this, which is that there is doesn't seem to be a generic way to pass options to pool activation 😅 so instead of trying to PR changes, I'm opening this to figure out what a plan to get this implemented would be!

[mulkieran]

@refi64 Thanks for raising this interesting topic. 'Till now, Stratis chooses a way of assembling the storage stack and controlling the interactions between the DM devices. I don't think that we would expect Stratis to handle an arbitrary, totally controlled by the user, choice of cryptsetup configuration flags for activation. However, these particular flags, offering as they do potentially large performance improvements, might be an interesting exception to that rule.

I think your point about pool "activation" is an interesting one. A pool is "activated" on creation and when it is "started", either by an explicit user command or when stratisd is started (if the pool is supposed to be started automatically). A user could, if they had the power to choose, toggle between using the workqueues and not, to assess the performance of their storage configuration.

[refi64]

I don't think that we would expect Stratis to handle an arbitrary, totally controlled by the user, choice of cryptsetup configuration flags for activation.

Ah I think I misstated myself: to be clear, when I said

This brings me to the problem I realized as I was adding this, which is that there is doesn't seem to be a generic way to pass options to pool activation

I wasn't referring to general mount / cryptsetup options, but more just the general fact that there Stratis provides no way of controlling anything like that, so there's no existing place where a toggle or similar could be added; it's all new design territory, essentially.