All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phillip Susi <psusi@cfl.rr.com>
To: dm-devel@redhat.com
Subject: Re: Device removal handling
Date: Mon, 11 Jul 2011 16:31:18 -0400	[thread overview]
Message-ID: <4E1B5D96.9090402@cfl.rr.com> (raw)
In-Reply-To: <20110711152343.GG7857@agk-dp.fab.redhat.com>

On 7/11/2011 11:23 AM, Alasdair G Kergon wrote:
> That's back-to-front!  You stop using a device first, then you remove it.
> You really don't want to be removing devices while they are in use if you
> can avoid it.

That is a pre plug and play world view.  These days the kernel needs to 
be able to handle surprise removal as well.  Also when you do want to 
remove a device, polluting user space tools with all kinds of hacks to 
try and figure out what the higher layers are and clean them up is very 
error prone and often is not done correctly.  It would be preferable to 
use the same mechanism to request the removal of a device, and let the 
kernel worry about notifying any higher layers to clean up.

> If something goes wrong and a device disappears, then yes, that disappearance
> should propagate up the stack to be handled as best it can by each layer.

The question then is, how should that work?  I can't believe the block 
layer does not already have some kind of mechanism for this.  It isn't 
much different than handling medium ejection.  If it does, then dm just 
needs to use it.

  reply	other threads:[~2011-07-11 20:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-10 20:12 Device removal handling Phillip Susi
2011-07-10 22:03 ` Alasdair G Kergon
2011-07-11 15:08   ` Phillip Susi
2011-07-11 15:23     ` Alasdair G Kergon
2011-07-11 20:31       ` Phillip Susi [this message]
2011-07-12  6:24     ` Hannes Reinecke
2011-07-12 10:58       ` Alasdair G Kergon
2011-07-13 15:53         ` Phillip Susi

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=4E1B5D96.9090402@cfl.rr.com \
    --to=psusi@cfl.rr.com \
    --cc=dm-devel@redhat.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.