[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v6 11/15] iotests: add 298 to test new preallocate filter dri
From: |
Thomas Huth |
Subject: |
Re: [PATCH v6 11/15] iotests: add 298 to test new preallocate filter driver |
Date: |
Thu, 1 Oct 2020 10:41:11 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 |
On 25/09/2020 17.11, Vladimir Sementsov-Ogievskiy wrote:
> 25.09.2020 12:11, Max Reitz wrote:
>> On 25.09.20 10:49, Vladimir Sementsov-Ogievskiy wrote:
>>> 25.09.2020 11:26, Max Reitz wrote:
>>>> On 18.09.20 20:19, Vladimir Sementsov-Ogievskiy wrote:
>>>>> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
>>>>> ---
>>>>> tests/qemu-iotests/298 | 186
>>>>> +++++++++++++++++++++++++++++++++++++
>>>>> tests/qemu-iotests/298.out | 5 +
>>>>> tests/qemu-iotests/group | 1 +
>>>>> 3 files changed, 192 insertions(+)
>>>>> create mode 100644 tests/qemu-iotests/298
>>>>> create mode 100644 tests/qemu-iotests/298.out
>>
>> [...]
>>
>>>>> +class TestTruncate(iotests.QMPTestCase):
>>>>
>>>> The same decorator could be placed here, although this class doesn’t
>>>> start a VM, and so is unaffected by the allowlist. Still may be
>>>> relevant in case of block modules, I don’t know.
>>>
>>> Or just global test skip at file top
>>
>> Hm. Like verify_quorum()? Is there a generic function for that already?
>>
>> [...]
>>
>>>>> + # Probably we'll want preallocate filter to keep align to
>>>>> cluster when
>>>>> + # shrink preallocation, so, ignore small differece
>>>>> + self.assertLess(abs(stat.st_size - refstat.st_size), 64 *
>>>>> 1024)
>>>>> +
>>>>> + # Preallocate filter may leak some internal clusters (for
>>>>> example, if
>>>>> + # guest write far over EOF, skipping some clusters - they
>>>>> will remain
>>>>> + # fallocated, preallocate filter don't care about such
>>>>> leaks, it drops
>>>>> + # only trailing preallocation.
>>>>
>>>> True, but that isn’t what’s happening here. (We only write 10M at
>>>> 0, so
>>>> there are no gaps.) Why do we need this 1M margin?
>>>
>>> We write 10M, but qcow2 also writes metadata as it wants
>>
>> Ah, yes, sure. Shouldn’t result in 1M, but why not.
>>
>>>>> + self.assertLess(abs(stat.st_blocks - refstat.st_blocks) *
>>>>> 512,
>>>>> + 1024 * 1024)
>>>>
>>>> [...]
>>>>
>>>>> diff --git a/tests/qemu-iotests/group b/tests/qemu-iotests/group
>>>>> index ff59cfd2d4..15d5f9619b 100644
>>>>> --- a/tests/qemu-iotests/group
>>>>> +++ b/tests/qemu-iotests/group
>>>>> @@ -307,6 +307,7 @@
>>>>> 295 rw
>>>>> 296 rw
>>>>> 297 meta
>>>>> +298 auto quick
>>>>
>>>> I wouldn’t mark it as quick, there is at least one preallocate=full of
>>>> 140M, and one of 40M, plus multiple 10M data writes and falloc
>>>> preallocations.
>>>>
>>>> Also, since you mark it as “auto”, have you run this test on all
>>>> CI-relevant hosts? (Among other things I can’t predict) I wonder how
>>>> preallocation behaves on macOS. Just because that one was always a bit
>>>> weird about not-really-data areas.
>>>>
>>>
>>> Ofcourse, I didn't run on all hosts. I'm a bit out of sync about this..
>>
>> Well, someone has to do it. The background story is that tests are
>> added to auto all the time (because “why not”), and then they fail on
>> BSD or macOS. We have BSD docker test build targets at least, so they
>> can be easily tested. (Well, it takes like half an hour, but you know.)
>>
>> (We don’t have macOS builds, as far as I can tell, but I personally
>> don’t even know why we run the iotests on macOS at all. (Well, I also
>> wonder about the BSDs, but given the test build targets, I shouldn’t
>> complain, I suppose.))
>>
>> (Though macOS isn’t part of the gating CI, is it? I seem to remember
>> macOS errors are generally only reported to me half a week after the
>> pull request is merged, which is even worse.)
>>
>> Anyway. I just ran the test for OpenBSD
>> (EXTRA_CONFIGURE_OPTS='--target-list=x86_64-softmmu' \
>> make vm-build-openbsd)
>
> Oh, I didn't know that it's so simple.
Running the tests on macOS is also quite simple if you have a github
account. You simply add the "Cirrus-CI" from the marketplace to your
forked qemu repository there, and then push your work to a branch in
that repo. Cirrus-CI then automatically tests your stuff on macOS (and
also FreeBSD), e.g.:
https://cirrus-ci.com/build/4961684689256448
Thomas