On Fri, 04/22 21:57, Jason Dillaman wrote: > Since this cannot automatically recover from a crashed QEMU client with an > RBD image, perhaps this RBD locking should not default to enabled. > Additionally, this will conflict with the "exclusive-lock" feature > available since the Ceph Hammer-release since both utilize the same locking > construct. > > As a quick background, the optional exclusive-lock feature can be > enabled/disabled on image and safely/automatically handles the case of > recovery from a crashed client. Under normal conditions, the RBD > exclusive-lock feature automatically acquires the lock upon the first > attempt to write to the image and transparently transitions ownership of > the lock between two or more clients -- used for QEMU live-migration.
Is it enabled by default? > > I'd be happy to add a new librbd API method to explicitly expose acquiring > and releasing the RBD exclusive lock since it certainly solves a couple > compromises in our current QEMU integration. Does the API do enable/disable or acquire/relase? Could you explain the differences between it and rbd_lock_exclusive? Fam