Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're busy

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Tue, Feb 21, 2012 at 09:38:41AM +0000, Jan Beulich wrote:
> >>> On 21.02.12 at 10:23, Andrew Jones <drjones@redhat.com> wrote:
> >> >>> On 20.02.12 at 11:35, Andrew Jones <drjones@redhat.com> wrote:
> >> >> On Fri, Feb 17, 2012 at 05:52:54PM +0100, Andrew Jones wrote:
> >> >> There was another fix that sounds similar to this in the backend.
> >> >> 6f5986bce558e64fe867bff600a2127a3cb0c006
> >> >> 
> >> > 
> >> > Thanks for the pointer. It doesn't look like the upstream 2.6.18
> >> > tree has that, but it probably would be a good idea there too.
> >> 
> >> While I had seen the change and considered pulling it in, I wasn't
> >> really convinced this is the right behavior here: After all, if the
> >> host
> >> admin requested a resource to be removed from a guest, it shouldn't
> >> depend on the guest whether and when to honor that request, yet
> >> by deferring the disconnect you basically allow the guest to continue
> >> using the disk indefinitely.
> >> 
> > 
> > I agree. Yesterday I wrote[1] asking if "deferred detach" is really
> > something we want. At the moment, Igor and I are poking through
> > xen-blkfront.c, and currently we'd rather see the feature dropped
> > in favor of a simplified driver. One that has less release paths,
> > and/or release paths with more consistent locking behavior.
> 
> I must have missed this, or it's one more instance of delayed mail
> delivery via xen-devel.
> 
> Konrad - care to revert that original change as having barked up
> the wrong tree?

Meaning the 6f5986bce558e64fe867bff600a2127a3cb0c006?

Lets CC Joe Jin here to get his input. I recall that the --force argument
still works with that patch so the admin can still choose to terminate the
state. Which I thought was the point of the --force - as in if the
guest is still using it, we won't be yanking it out until we are
completly sure.


> 
> Jan
> 
> > [1] http://lists.xen.org/archives/html/xen-devel/2012-02/msg01672.html 
>