Jason Dillaman

> At least the librbd objects `ImageCtx` and `ObjectCacher`, which are both created when opening an image with `rbd_open()`, are keeping pointers to a `CephContext` object [here](https://github.com/ceph/ceph/blob/v14.2.6/src/librbd/ImageCtx.h#L68) and [here](https://github.com/ceph/ceph/blob/v14.2.6/src/osdc/ObjectCacher.h#L56), that...

> I would consider this clearly a bug now, because a successful removal of the image should indicate, that it's safe to shit down the handle. I agree that it's...

> I would still say it's misleading that it's possible to "remove" an opened image, if it doesn't actually destroy it. "Remove" is about removing the backing data from the...

> I do not like duplicating the work done in the `rbd` command. There are also options for krbd and ndb-rbd, so it would be required to (re)implement both ways....

https://tracker.ceph.com/issues/43906 https://tracker.ceph.com/issues/43907

> Poking around a bit more, and it appears this isn't in any released versions of ceph yet, not even octopus, so it would appear we'd need to wait a...

Perhaps the biggest current limitation of NBD is that the rbd-nbd daemon is run within the ceph-csi container. Upgrading the container is not possible w/o killing running workloads. There are...

> We can't upgrade the RBD client either without killing the container as long as we are using kRBD, but I assume the concern is the reverse - about our...

I don't believe anyone is working on it -- and it really doesn't make much sense since `rbd-nbd` isn't really production worthy (right now), so we wouldn't want to encourage...

This [1] provides a really good overview and a theoretical timeline [1] https://medium.com/nttlabs/cgroup-v2-596d035be4d7