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.
next prev parent 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.