Add persistent and perf options to the luks_device

[jsirex]

Read and write work queue significantly degrades performance on
SSD/NVME devices[1].

In Debian 11 crypttab does not support no-read-workqueue and
no-write-workqueue flags, so the persistent flag is workaround: once
opened with perf parameters persists forever.

[1] https://blog.cloudflare.com/speeding-up-linux-disk-encryption/

Signed-off-by: Yauhen Artsiukhou jsirex@gmail.com

Fixes: #427

[jsirex]

I don't know python/ansible well enough so feel free to rewrite PR

[MarkusTeufelberger]

Thanks a lot for the feature! :-)

Maybe you can think of some ways to test/ensure this is actually applied? They would go here: https://github.com/ansible-collections/community.crypto/tree/main/tests/integration/targets/luks_device/tasks/tests

Also if there are already limitations on Debian11, there might be other ones too, these should be documented at least.

[jsirex]

Regarding Debian 11 - I think it is temporary bug. Cryptsetup supports everything, but crypttab-related scripts where not updated yet. So it doesn't relate to this collection at all.

Speaking about test - its quite hard for me: after luks container is opened you must check it with
dmsetup table <device> and check persistence with cryptsetup luksDump <device> for flags. I'm not ready now to do this.
Anyway tested locally with vagrant. And I'm not sure we should re-test library functions (that cryptsetup flags work), I just pass them.

[jsirex]

Added some tests, but looks like kernel too old.

[felixfontein]

Thanks for your contribution!

[felixfontein]

Looks good to me.

[MarkusTeufelberger]

Do we also need a changelog fragment?

[MarkusTeufelberger]

Other than that looks good to me too - sorry for causing this much hassle just to add a literal handful of parameters to a command... but in the end it is important that documentation is available and there are no immediate regressions or problems down the line.

I'm sure this feature will be appreciated by users, especially since Cloudflare detailed how to actually get decent performance on encrypted setups on modern systems, thanks for adding it!

[jsirex]

Hi!
One last thought: I see that cryptsetup uses options prefixed with --perf-, however in the crypttab and dmsetup there is no such prefix. If it makes sense I can remove perf_ from options:

perf_same_cpu_crypt -> same_cpu_crypt
perf_submit_from_crypt_cpus -> submit_from_crypt_cpus
perf_no_read_workqueue -> no_read_workqueue
perf_no_write_workqueue -> no_write_workqueue

[felixfontein]

One last thought: I see that cryptsetup uses options prefixed with --perf-, however in the crypttab and dmsetup there is no such prefix. If it makes sense I can remove perf_ from options:

perf_same_cpu_crypt -> same_cpu_crypt
perf_submit_from_crypt_cpus -> submit_from_crypt_cpus
perf_no_read_workqueue -> no_read_workqueue
perf_no_write_workqueue -> no_write_workqueue

Hmm, that's a tough question (IMO). I wish they'd be more consistent :)

Keeping the prefix ensures that these four options will be shown next to each other in the documentation. For me this slightly tips the scale to "keep the prefix".

[felixfontein]

@jsirex thanks for contributing this!
@MarkusTeufelberger thanks for reviewing!