qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Regression from 2.8: stuck in bdrv_drain()


From: Eric Blake
Subject: Re: [Qemu-devel] Regression from 2.8: stuck in bdrv_drain()
Date: Thu, 13 Apr 2017 09:45:49 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

On 04/13/2017 09:39 AM, Stefan Hajnoczi wrote:
> On Thu, Apr 13, 2017 at 01:45:55PM +0800, Paolo Bonzini wrote:
>>
>>
>> On 13/04/2017 09:11, Jeff Cody wrote:
>>>> It didn't make it into 2.9-rc4 because of limited time. :(
>>>>
>>>> Looks like there is no -rc5, we'll have to document this as a known issue.
>>>> Users should "block-job-complete/cancel" as soon as possible to avoid such 
>>>> a
>>>> hang.
>>>
>>> I'd argue for including a fix for 2.9, since this is both a regression, and
>>> a hard lock without possible recovery short of restarting the QEMU process.
>>
>> It is a bit of a corner case (and jobs on I/O thread are relatively rare
>> too), so maybe it's not worth delaying 2.9.  It has been delayed already
>> quite a bit.  Another reason I think I prefer to wait is to ensure that
>> we have an entry in qemu-iotests to avoid the future regression.
> 
> I also think this does not require delaying the release:
> 
> 1. It needs to be marked as a known issue in the release notes.
> 2. Let's roll the 2.9.1 stable release within a month of 2.9.0.
> 
> If both conditions are met then very few end users will be exposed to
> the problem.  I hope libvirt will create IOThreads by default soon but
> for the time being it is not a widely used configuration.

Also, is it something that can be avoided by not doing a system_reset
while a block job is still running? Libvirt can be taught to block reset
while a job has still not been finished, if needs be.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]