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.
FYI, this bit me in a PVE8 to PVE9 upgrade. After upgrading one node, the new PVE 7.0 kernel cannot configure resources from linstor:
root@virtual5:/home/brian# journalctl -eu linstor-satellite
...
Oct 08 03:21:08 virtual5 Satellite[2541]: 2026-10-08 03:21:08.717 [DeviceManager] INFO LINSTOR/Satellite/479904 SYSTEM - DRBD regenerated resource file: /var/lib/linstor.d/linstor_db.res
...
Oct 08 03:21:08 virtual5 Satellite[2541]: 2026-10-08 03:21:08.807 [DeviceManager] ERROR LINSTOR/Satellite/479904 SYSTEM - Restoring resource file from backup: linstor_db
Oct 08 03:21:08 virtual5 Satellite[2541]: 2026-10-08 03:21:08.818 [DeviceManager] ERROR LINSTOR/Satellite/479904 SYSTEM - Failed to adjust DRBD resource linstor_db [Report number 6AC76E6D-B63BE-000000]
brian@virtual1:~$ linstor error-reports show 6AC76E6D-B63BE-000000
...
drbdsetup new-peer linstor_db 0 --_name=virtual1 --verify-alg=crct10dif --shared-secret=kEZ97aaMcMPv7Amb6reY --cram-hmac-alg=sha1
The external command sent the following error information:
[ne] minor 1002 (vol:0) /dev/sata_ssd/linstor_db_00000 missing from kernel
linstor_db: Failure: (146) VERIFYAlgNotAvail
additional info from kernel:
failed to allocate crct10dif for verify
Command 'drbdsetup new-peer linstor_db 0 --_name=virtual1 --verify-alg=crct10dif --shared-secret=kEZ97aaMcMPv7Amb6reY --cram-hmac-alg=sha1' terminated with exit code 10
drbdadm: new-peer linstor_db: skipped due to earlier error
So I’d strongly suggest fixing up the verify-alg before doing an upgrade. I’m going to have to try to sort it mid-upgrade
Good news: linstor c sp DrbdOptions/auto-verify-algo-disable true was enough to bring all the drbd resources back to life. After this, verify-alg is no longer present in /var/lib/linstor.d/*.res. Then linstor c opt --verify-alg sha256 adds it back in again.
Bad news: DrbdOptions/auto-verify-algo-disable true also disables cram-hmac-alg and shared-secret in the network connection parameters. You can end up in a state where the resource has this enabled on one side but not the other (depending on when linstor satellites are restarted), so they refuse to connect until this is resolved.
