What are you looking for in lsof? Did you try looking for the major/minor number of the rbd device? Things that could hold the device are devicemapper, lvm, swraid and possibly many more, not sure if all that shows in lsof output... Jan > On 25 Sep 2015, at 18:41, Jeff Epstein <jeff.epstein@xxxxxxxxxxxxxxxx> wrote: > > On 09/25/2015 12:38 PM, Ilya Dryomov wrote: >> On Fri, Sep 25, 2015 at 7:17 PM, Jeff Epstein >> <jeff.epstein@xxxxxxxxxxxxxxxx> wrote: >>> We occasionally have a situation where we are unable to unmap an rbd. This >>> occurs intermittently, with no obvious cause. For the most part, rbds can be >>> unmapped fine, but sometimes we get this: >>> >>> # rbd unmap /dev/rbd450 >>> rbd: sysfs write failed >>> rbd: unmap failed: (16) Device or resource busy >> Does it persist, i.e. can you unmap a few seconds after this? > It seems to persist. We've been struggling with this for a few days. >>> Is there any way to determine what exactly is blocking the unmap? Is there a >>> way to force unmap? >> No, there is no way to force unmap. The most likely reason for -EBUSY >> is a positive open_count, meaning something has that device opened at >> the time you do unmap. I guess we could start outputting open_count to >> dmesg in these cases, just to be sure. > > Is there any way to query the open_count? Or to forcibly reset it if it becomes inaccurate? > > Jeff > _______________________________________________ > ceph-users mailing list > ceph-users@xxxxxxxxxxxxxx > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |