From: Kevin Corry <kevcorry@us.ibm.com>
To: dm-devel@sistina.com, Daniel Phillips <dphillips@sistina.com>,
Linux Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [dm-devel] Re: [RFC] device-mapper ioctl interface
Date: Thu, 5 Jun 2003 12:50:30 -0500 [thread overview]
Message-ID: <200306051250.30994.kevcorry@us.ibm.com> (raw)
In-Reply-To: <200306051900.37276.dphillips@sistina.com>
On Thursday 05 June 2003 12:00, Daniel Phillips wrote:
> On Thursday 05 June 2003 18:47, Kevin Corry wrote:
> > 2) Removing suspended devices. The current code (2.5.70) does not allow a
> > suspended device to be removed/unlinked from the ioctl interface, since
> > removing it would leave you with no way to resume it (and hence flush any
> > pending I/Os). Alasdair mentioned a couple of new ideas. One would be to
> > reload the device with an error-map and force it to resume, thus erroring
> > any pending I/Os and allowing the device to be removed. This seems a bit
> > heavy-handed.
>
> Which is the heavy-handed part?
The part about automatically reloading the table with an error map and forcing
it to resume. It just seemed to me that user-space ought to be able to gather
enough information to determine that a device needed to be resumed before it
could be removed. Thus the kernel driver wouldn't be forced to implement such
a policy.
Talking with Alasadair again, he mentioned a case I hadn't considered. Devices
would now be created without a mapping and initially suspended. If some other
error occurred, and you decided to just delete the device before loading a
mapping, it would fail. And having to resume a device with no mapping just
to be able to delete it definitely seems odd.
So, it's not like I'm dead-set against this idea. I was just curious what the
reasoning was behind this change.
--
Kevin Corry
kevcorry@us.ibm.com
http://evms.sourceforge.net/
next prev parent reply other threads:[~2003-06-05 17:37 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-05 9:39 [RFC] device-mapper ioctl interface Joe Thornber
2003-06-05 16:47 ` Kevin Corry
2003-06-05 17:00 ` [dm-devel] " Daniel Phillips
2003-06-05 17:50 ` Kevin Corry [this message]
2003-06-05 18:53 ` Daniel Phillips
2003-06-05 19:41 ` Joe Thornber
2003-06-06 16:11 ` Kevin Corry
2003-06-06 17:17 ` Greg KH
2003-06-06 19:53 ` [dm-devel] " Alasdair G Kergon
2003-06-09 20:03 ` Daniel Phillips
2003-06-09 20:39 ` Greg KH
2003-06-09 21:39 ` Daniel Phillips
2003-06-09 22:08 ` Daniel Phillips
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=200306051250.30994.kevcorry@us.ibm.com \
--to=kevcorry@us.ibm.com \
--cc=dm-devel@sistina.com \
--cc=dphillips@sistina.com \
--cc=linux-kernel@vger.kernel.org \
/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.