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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 21.02.12 at 10:23, Andrew Jones <drjones@xxxxxxxxxx> wrote:
>> >>> On 20.02.12 at 11:35, Andrew Jones <drjones@xxxxxxxxxx> 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?

Jan

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



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xensource.com/xen-devel