Hello.
I came across commit https://github.com/torvalds/linux/commit/8522104f75bf1ce33d76ea425185da2a7fba5a70 indicating that support for the crct10dif algorithm was removed from the Linux kernel. Consequently, I decided to test the crc32c algorithm. During testing of verification algorithms in LINSTOR, I encountered ambiguous behavior regarding property inheritance and how values are displayed across different levels.
OS: Ubuntu 24.04
LINSTOR Controller/Satellite: 1.33.1
DRBD version: 9.3
I attempted to change the verification algorithm at the Resource Group level using the following command: linstor rg opt --verify-alg crc32c test
As expected, the new value is visible at the Resource Group level:
root@test-node2:~# linstor rg lp test
+-----------------------------------------------------------+
| Key | Value |
|-----------------------------------------------------------|
| DrbdOptions/Net/verify-alg | crc32c |
+-----------------------------------------------------------+
However, when checking the Resource Definition properties, I still see a different key with the old value:
root@test-node2:~# linstor rd lp test
+---------------------------------------------------+
| Key | Value |
|---------------------------------------------------|
| DrbdOptions/auto-verify-alg | crct10dif |
+---------------------------------------------------+
Interestingly, the actual DRBD configuration correctly reflects the new setting. In the DRBD config, I see the new algorithm that I assigned to the Resource Group:
root@test-node3:~# drbdsetup show test
...
net {
verify-alg "crc32c";
}
...
I can see that DRBD receives the correct configuration, but after changing the verification algorithm on the Resource Group, I expected this change to be reflected in the Resource Definition as well. The simultaneous coexistence of auto-verify-alg and verify-alg creates confusion from an administrative perspective.
I would appreciate a clarification on the proper way to change the verification algorithm in LINSTOR.
Is it possible to change the default algorithm for auto-verify-alg?
Why is this property not updated or hidden when verify-alg is explicitly defined at the Resource Group level?
Aside: have you found this option documented anywhere? I see it in the linstor source code, but I don’t see it in the linstor manual. (I’m sure it’s valid - linstor does validate the property names - but I’d like to understand the semantics)
Also, I’m not sure if resource-definition list-properties shows properties which are inherited from the resource group - and if it does, whether it’s possible to distinguish between inherited and explicitly-set properties.
Could you please explain how the parameter DrbdOptions/auto-verify-algo-allowed-user-list works?
Does it restrict the selection of the verification algorithm from the list DrbdOptions/auto-verify-algo-allowed-list for the parameter DrbdOptions/auto-verify-alg?
the auto-verify-algo-allowed-user-list allows additional shash algorithms to be considered by Linstor, so it doesn’t override the linstor list, just expand it.
@rp9 Hello Rene! if you have a moment, I’d appreciate it if you could answer my questions.
In our current Linstor configuration, the crct10dif algorithm is used for the DrbdOptions/auto-verify-alg parameter.
We would like to clarify the system behavior in case of an operating system upgrade where this algorithm crct10dif may be unavailable or not present in the kernel:
Will Linstor automatically select an alternative available algorithm for the DrbdOptions/auto-verify-alg parameter?
Is it possible to explicitly control the selection of the algorithm for DrbdOptions/auto-verify-alg, and if so, what is the recommended approach?
From a best practice perspective, would it be more appropriate to explicitly configure DrbdOptions/Net/verify-alg and fix the algorithm manually instead of using DrbdOptions/auto-verify-alg?
Which approach is generally recommended in production environments: relying on DrbdOptions/auto-verify-alg or explicitly setting DrbdOptions/Net/verify-alg?
Additionally, we have observed in our test scenario that the DrbdOptions/Net/verify-alg parameter takes precedence over DrbdOptions/auto-verify-alg (provided it is not disabled). Could you please confirm whether this behavior is expected?
Yes, that is why there is the auto-verify-algorithm option, it will get all available kernel algorithms
and choose the highest common priority algorithm.
Yes, you would set the DrbdOptions/auto-verify-algo-disable property on controller or resource-group level. e.g.: linstor c sp DrbdOptions/auto-verify-algo-disable true
and if you want an explicit one set it also on controller or resource-groupe level e.g.: linstor c opt --verify-alg sha256
If you don’t use drbdadm verify at all, you could simply disable it, as it saves some communication cycles and maybe drbd adjusts. Or as in the example above set a
algorithm that will avialable on all platforms like sha256.
Yes, I’m pretty sure this is intended to give the users choice the higher priority.