Hey, I’m currently preparing a long overdue move from the traditional advisory locks to the exclusive-lock feature and am a bit perplexed by the situation. I’d love some feedback whether I’m missing something or not. We currently use the advisory locks to determine whether it’s safe to start a VM or not. We use exclusive advisory locks on the RBD images that belong to a VM so that we get guaranteed atomicity: if we get the lock, then we’re good to go. The exclusive locks are incompatible with this as they build on the same infrastructure but with different semantics. As the docs say: exclusive locks are used to protect the RBD-internal objects (so the data on the RADOS layer) from being inconsistently manipulated but they will only serialize RBD-level concurrent access. There are some parts of the tool chain that allow having a single client (map --exclusive) but this isn’t consistently exposed and not useful as it AFAICT will undermine the ability for concurrent internal tasks like mirrorin/migration/… Now, the docs also talk about fencing - however - that seems to be missing the original atomicity promise: I can fence (blocklist) a known other client, but I can not be sure that no other client appeared in between. Without atomicity I can’t safely start using this volume. This issue can be solved on a higher level orchestrator, but at that point one loses the ability for consistent low level access to volumes (e.g. for backups, debugging or other tasks). Am I describing the situation accurately? Is this the way it is on purpose or is there room for improvement here? Thanks, Christian -- Christian Theune · ct@flyingcircus.io · +49 345 219401 0 Flying Circus Internet Operations GmbH · https://flyingcircus.io Leipziger Str. 70/71 · 06108 Halle (Saale) · Deutschland HR Stendal HRB 21169 · Geschäftsführer: Christian Theune, Christian Zagrodnick