Messages in this thread | | | From | Daniel Phillips <> | Subject | Re: [dm-devel] Re: [RFC] device-mapper ioctl interface | Date | Thu, 5 Jun 2003 20:53:57 +0200 |
| |
On Thursday 05 June 2003 19:50, Kevin Corry wrote: > 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.
I didn't see anything about doing that in-kernel.
> 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.
It's similar to the way a lot of things work in Linux: you have to let operations run to completion so they can let go of resources. One day we'll be able to shoot down transfers in mid-flight, but I doubt that's going to happen in this cycle.
So in general, the idea is: let any outstanding operations complete, but feed them errors. What else can we do?
I don't see this as heavyweight at all. Policy stays in user space, and a lightweight error path lives in the kernel.
Regards,
Daniel
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |