Resource delete + recreate on DRBD sometimes results in out-of-sync data about linstor-server HOT 5 CLOSED

I happened to test mixing thin and thick pools yesterday too and observed a similar issue. In my tests, the problem only occurred when adding a resource on a thin pool to a resource definition which already had resources on thick pools. From your description, it appears that you are doing the opposite. Could you re-run your tests and check whether the new resource that you are adding is added on a thin or thick pool?

I also noticed that the resource create command appeared to complete successfully even though the resources were StandAlone (split brain). We have an internal ticket to ensure that an appropriate error is generated. We have a second ticket to fix the mixed thin/thick situation, it's interesting to discover that someone is actually using such a setup.

from linstor-server.

The reason I have a mixed thin/thick setup is that I'm actually trying to migrate away from thin pools. Too much overhead especially on rotating disks, serious problems when metadata fills up etc.

As for rerunning the test, DRBD9 unfortunately seems to be acting up in other ways right night now, so my test results might not be reliable. (I'm getting stuff like Digest mismatch, buffer modified by upper layers during write even with EXT4 defaults and QEMU cache mode as directsync, suddenly vanishing dev links at /dev/drbd/by-res/ and
[37958.172279] drbd vm-100-disk-1/0 drbd1018 mox-a: Online verify found 18446744073709550592 4k blocks out of sync!, while the resource is obviously not 64 zettabytes.)

from linstor-server.

Mixing fat/thin provisioning is only supported on the resource level, but not on the volume level (e.g. one fat volume and one thin volume in the same resource works, but one fat volume on one node and one thin volume on another node does not).
Additionally, with thin provisioning, some of the behavior (connection dropping and split brain) may also be caused by the other peers having used or cleaned up all available peer slots, thereby causing a mismatch of the peers' meta data bitmap generation with the newly created resource's initial generation.
This does not occur with fat provisioned volumes, because those fat provisioned volumes always contain clean/initial meta data that results in a full sync from another peer.

from linstor-server.

Could a mixing thin and thick on different servers be detected? If it's not supported and can lead to problems, maybe the tools should refuse to do so?

from linstor-server.

This is refused now.

from linstor-server.