[dm-devel] [PATCH] dm-crypt: Document new no_workqueue flags.

[Milan Broz]

On 24/08/2020 03:15, Damien Le Moal wrote:
> On 2020/08/21 2:46, Milan Broz wrote:
>> Patch 39d42fa96ba1b7d2544db3f8ed5da8fb0d5cb877 introduced new
>> dm-crypt no_read_workqueue and no_write_workqueue flags.
>>
>> This patch adds documentation to admin guide for them.
>>
>> Signed-off-by: Milan Broz <gmazyland at gmail.com>
>> ---
>>  Documentation/admin-guide/device-mapper/dm-crypt.rst | 6 ++++++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/Documentation/admin-guide/device-mapper/dm-crypt.rst b/Documentation/admin-guide/device-mapper/dm-crypt.rst
>> index 8f4a3f889d43..94466921415d 100644
>> --- a/Documentation/admin-guide/device-mapper/dm-crypt.rst
>> +++ b/Documentation/admin-guide/device-mapper/dm-crypt.rst
>> @@ -121,6 +121,12 @@ submit_from_crypt_cpus
>>      thread because it benefits CFQ to have writes submitted using the
>>      same context.
>>  
>> +no_read_workqueue
>> +    Bypass dm-crypt internal workqueue and process read requests synchronously.
>> +
>> +no_write_workqueue
>> +    Bypass dm-crypt internal workqueue and process write requests synchronously.
> 
> Could you add one more line here saying something like:
> 
> This option is automatically enabled for host-managed zoned block devices (e.g.
> host-managed SMR hard-disks).

Yes, Mike can squeeze it there (Mike, if you prefer, I can resend the patch with the note above).

I just see one problem here - when we activate device without these flags,
then dm-crypt decides to set the feature bits because of zone device.

So you activate device with some feature set but table will show something different.
It is not a technical problem, but I think DM table was not expected to behave this way.

It is probably not the first change (I think some flags are activated in dm-integrity
according to on-disk superblock state only).

Milan

p.s. Both noqueue flags are now supported in cryptsetup master, for LUKS2 we can store them persistently
(IOW to be used in all later LUKS2 activations if kernel supports it).
It should appear in next stable cryptsetup release.