On Mon, Jan 4, 2016 at 10:51 AM, Wukongming <wu.kongm...@h3c.com> wrote:
> Hi, Ilya,
>
> It is an old problem.
> When you say "when you issue a reboot, daemons get killed and the kernel
> client ends up waiting for the them to come back, because of outstanding
> writes issued by umount called by systemd (or whatever)."
>
> Do you mean if umount rbd successfully, the process of kernel client will
> stop waiting? What kind of Communication mechanism between libceph and
> daemons(or ceph userspace)?
If you umount the filesystem on top of rbd and unmap rbd image, there
won't be anything to wait for. In fact, if there aren't any other rbd
images mapped, libceph will clean up after itself and exit.
If you umount the filesystem on top of rbd but don't unmap the image,
libceph will remain there, along with some amount of communication
(keepalive messages, watch requests, etc). However, all of that is
internal and is unlikely to block reboot.
If you don't umount the filesystem, your init system will try to umount
it, issuing FS requests to the rbd device. We don't want to drop those
requests, so, if daemons are gone by then, libceph ends up blocking.
Thanks,
Ilya
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
