qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 0/2] mirror dead-lock


From: Max Reitz
Subject: Re: [Qemu-devel] [PATCH v2 0/2] mirror dead-lock
Date: Mon, 3 Dec 2018 15:26:11 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1

On 03.12.18 15:13, Vladimir Sementsov-Ogievskiy wrote:
> 03.12.2018 16:59, Max Reitz wrote:
>> On 29.11.18 11:17, Vladimir Sementsov-Ogievskiy wrote:
>>> Hi all!
>>>
>>> v2: add fix:)
>>>
>>> We've faced the following mirror bug:
>>>
>>> Just run mirror on qcow2 image more than 1G, and qemu is in dead lock.
>>
>> So because apparently there is going to be an rc4 anyway (like basically
>> always...), I'd really like to bring this fix into it, unless there are
>> any objections from anyone (though all of you are more than welcome to
>> explicitly agree, too :-)).
>>
>> Do you have any plans for the iotest?  Right now, I'd rather just take
>> patch 1 as-is and add the test later, but then again, adding a patch for
>> rc4 without a test is not so nice either, I suppose.
>>
>> Max
>>
> 
> I think, everything is better with test:) I can't say that I really like your
> additions, because it's anyway a kind of cheating, less real-life,

You mean like all iotests? ;-)

iotests usually only test a single specific thing and not a full
real-life case.

>                                                                    but on the
> other hand, as I understand, allocating a lot of disk space in iotests is a 
> bad
> thing too.
> 
> May be it should be a kind of parameter, with default to your variant, 
> something
> like ./check --big-disk-allocations-allowed :).

As I said, we would need to add a new group (e.g. "big-disk-allocation")
and then probably disable that group in check by default.  You could run
those tests with ./check -g big-disk-allocation.

> But let's commit at least the test with your additions.

I mean, we can also add both tests.  But I should say that your version
did not fail on tmpfs before this fix, and I usually run tests on tmpfs,
so...  It wouldn't be very indicative of the issue for me.

Max

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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