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?
>
> Things we've tried: lsof doesn't provide any useful information. We are sure
> the rbd isn't mapped anywhere. listwatchers shows that there is a watcher on
> the current host, and nowhere else. The given rbd has an associated jbd2
> process, but no kworker. Other rbds are able to map and unmap fine.
>
> I should also mention that for the time being we are using rbd v1 images.
unmap process for v1 and v2 images is the same.
>
> # ceph --version
> ceph version 0.87 (c51c8f9d80fa4e0168aa52685b8de40e42758578)
> # uname -srvom
> Linux 4.1.6pl #1 SMP Mon Sep 7 22:43:13 CEST 2015 x86_64 GNU/Linux
>
> 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.
Thanks,
Ilya
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
