qemu-stable
[Top][All Lists]
Advanced

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

Re: [Qemu-stable] [PATCH v2 2/2] iotests: simple mirror test with kvm on


From: Vladimir Sementsov-Ogievskiy
Subject: Re: [Qemu-stable] [PATCH v2 2/2] iotests: simple mirror test with kvm on 1G image
Date: Fri, 30 Nov 2018 13:48:55 +0000

30.11.2018 16:13, Max Reitz wrote:
> On 30.11.18 14:06, Vladimir Sementsov-Ogievskiy wrote:
>> 30.11.2018 15:30, Max Reitz wrote:
>>> On 29.11.18 11:18, Vladimir Sementsov-Ogievskiy wrote:
>>>> This test is broken without previous commit fixing dead-lock in mirror.
>>>>
>>>> Signed-off-by: Vladimir Sementsov-Ogievskiy<address@hidden>
>>>> ---
>>>>    tests/qemu-iotests/235     | 59 ++++++++++++++++++++++++++++++++++++++
>>>>    tests/qemu-iotests/235.out |  1 +
>>>>    tests/qemu-iotests/group   |  1 +
>>>>    3 files changed, 61 insertions(+)
>>>>    create mode 100755 tests/qemu-iotests/235
>>>>    create mode 100644 tests/qemu-iotests/235.out
>>> I'll get to the first patch in a second, but first a suggestion for this
>>> patch: I think it's not so good to use 2 GB of space for a test (1 GB
>>> for the source, 1 GB for the target).  So I tried my luck and found that
>>> the test works, too, if you just use preallocation=metadata for the
>>> source (instead of actually writing data) and blockdev-mirror'ing the
>>> data to a throttled null-co device.
>>
>> Hmm, so parsing metadata is enough for qcow2 to yield on write, yes?
> 
> Apparently so.  If you can confirm that applying those changes to the
> test still make it work (i.e., fail before patch 1, pass afterwards),
> then I think it is just as good.

Ok, I've checked that your changes works for me.

hm, but we write to null, so, yield on write comes from throttling, however,
without preallocation=metadata, it don't work.., do you know, why we need
preallocation to reproduce?


> 
> [...]
> 
>> anyway, it's good thing to avoid 2G allocation in test, I agree.
> 
> And if for some reason the test needs to keep doing that, I'd propose
> adding some new test group for tests that do use such a large amount of
> disk space so it can be excluded if people don't want that to happen.
> 
> Max
> 


-- 
Best regards,
Vladimir

reply via email to

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