Thanks Ilya. I am indeed using lock ls command with workload ID
corresponding to the lock tag - works reasonably well. I was just wondering
if there were better options. Thanks for all the inputs.
Thanks
Shridhar
On Mon, Apr 13, 2020 at 4:23 AM Ilya Dryomov wrote:
> Tying this with your other t
Tying this with your other thread, if you always take a lock before
mapping an image, you could just list the lockers. Unlike a watch,
a lock will never disappear behind your back ;)
Thanks,
Ilya
On Thu, Apr 9, 2020 at 9:24 PM Void Star Nill wrote:
>
> Thanks Ilya. Is there a m
Thanks Ilya. Is there a more deterministic way to know where the volumes
are mapped to?
Thanks,
Shridhar
On Wed, 8 Apr 2020 at 03:06, Ilya Dryomov wrote:
> A note of caution, though. "rbd status" just lists watches on the
> image header object and a watch is not a reliable indicator of whethe
A note of caution, though. "rbd status" just lists watches on the
image header object and a watch is not a reliable indicator of whether
the image is mapped somewhere or not.
It is true that all read-write mappings establish a watch, but it can
come and go due to network partitions, OSD crashes o
Thanks Jack. Exactly what I needed.
Appreciate quick response.
Regards,
Shridhar
On Tue, 7 Apr 2020 at 10:00, Jack wrote:
> Hi,
>
> Checkout rbd status
> For instance:
> root@ceph5-1:~# rbd status vm-903-disk-1
> Watchers:
> watcher=10.5.0.39:0/866486904 client.522682726
> cookie=140
Hi,
Checkout rbd status
For instance:
root@ceph5-1:~# rbd status vm-903-disk-1
Watchers:
watcher=10.5.0.39:0/866486904 client.522682726 cookie=140177351959424
This is the list of clients for that image
All mapping hosts are in it
On 4/7/20 6:46 PM, Void Star Nill wrote:
> Hello,
>
> I
