All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Durgin <josh.durgin@inktank.com>
To: Travis Rhoden <trhoden@gmail.com>
Cc: ceph-devel@vger.kernel.org
Subject: Re: can "rbd unmap" detect if device is mounted?
Date: Mon, 16 Jul 2012 15:43:08 -0700	[thread overview]
Message-ID: <500498FC.9070806@inktank.com> (raw)
In-Reply-To: <CACkq2mqt5ae4U_-yhNM94GYQnE_negqXqHTf3JaSZ0zsxya9Yw@mail.gmail.com>

On 07/16/2012 12:59 PM, Travis Rhoden wrote:
> Hi folks,
>
> I've made this mistake a couple of times now (completely my fault,
> when will I learn?), and am wondering if a bit of protection can be
> put in place against user errors.

Yeah, we've been working on advisory locking. The first step is
just adding an option to lock via the rbd command line tool, so you
could script lock/map and unmap/unlock.

This is described a little more in this thread:

http://comments.gmane.org/gmane.comp.file-systems.ceph.devel/7094

> I mapped a device "rbd map", then formatted and and mounted the device
> ("mkfs.extf /dev/rbd0..., mount /dev/rbd0...").  Then sometime later,
> I want to remove the RBD device.  Stupidly, I do the "rbd unmap"
> command before I unmount the device.  The kernel doesn't really care
> for this.  Or more accurately, I can't remap that same RBD because I
> run into:
>
> kernel: [2248653.941688] sysfs: cannot create duplicate filename
> '/devices/virtual/block/rbd0'
> ....
> kernel: [2248653.941833] kobject_add_internal failed for rbd0 with
> -EEXIST, don't try to register things with the same name in the same
> directory.
>
> At this point, the "rbd map" command hangs indefinitely (producing the
> logs from above).  Ctrl-C does exit out, though.  But if I try to fix
> my mistake by doing the unmount now, I get the error:
>
> umount: device is busy.
>
> So really I get stuck.  I can't unmount without the device, and I
> can't remap the device to the old block device.  I have to reboot to
> clean up and move on.

A similar issue was fixed in 3.4 (see 
http://tracker.newdream.net/issues/1907).
What kernel are you using? 3.2 had a nasty possibility of preventing
further operations if mapping hung while trying to connect to the
monitors.

> I imagine other bad things can happen with the block device goes away
> out from under the mount point.  Any way the "rbd unmap" command can
> detect when the device is in use or mounted and inform the user?

Before actually unmapping the device, rbd unmap could check if it was
present in mtab. If it's being used as a raw block device and not
mounted or you created and used your own device node this wouldn't
help, but it would be better than nothing.

Josh

  reply	other threads:[~2012-07-16 22:43 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-16 19:59 can "rbd unmap" detect if device is mounted? Travis Rhoden
2012-07-16 22:43 ` Josh Durgin [this message]
2012-07-16 23:00   ` Travis Rhoden
2012-07-16 23:37   ` Tommi Virtanen
2012-07-17  0:43     ` Josh Durgin
2012-07-17  3:34     ` Travis Rhoden

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=500498FC.9070806@inktank.com \
    --to=josh.durgin@inktank.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=trhoden@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.