On Tue, Apr 26, 2016 at 7:20 PM, Fam Zheng <f...@redhat.com> wrote: > On Tue, 04/26 10:42, Jason Dillaman wrote: >> On Sun, Apr 24, 2016 at 7:42 PM, Fam Zheng <f...@redhat.com> wrote: >> > 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? >> > >> >> Starting with the Jewel release of Ceph it is enabled by default. > > OK, then I'll leave rbd in this QEMU series for now.
Without exposing some new API methods, this patch will, unfortunately, directly conflict with the new Jewel rbd defaults and will actually result in the image becoming read-only since librbd won't be able to acquire the exclusive lock when QEMU owns the advisory lock. We can probably get the new API methods upstream within a week or two [1]. If that's too long of a delay, I'd recommend dropping rbd locking from the series for now. [1] http://tracker.ceph.com/issues/15632 -- Jason
