qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 2/2] qemu-iotests: add multiwrite test cases


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH v2 2/2] qemu-iotests: add multiwrite test cases
Date: Wed, 30 Jul 2014 05:19:16 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

On 07/30/2014 02:53 AM, Stefan Hajnoczi wrote:
> This test case covers the basic bdrv_aio_multiwrite() scenarios:
> 1. Single request
> 2. Sequential requests (AABB)
> 3. Superset overlapping requests (AABBAA)
> 4. Subset overlapping requests (BBAABB)
> 5. Head overlapping requests (AABB)
> 6. Tail overlapping requests (BBAA)
> 7. Disjoint requests (AA BB)
> 
> Signed-off-by: Stefan Hajnoczi <address@hidden>
> ---
>  tests/qemu-iotests/100     | 134 
> +++++++++++++++++++++++++++++++++++++++++++++
>  tests/qemu-iotests/100.out |  89 ++++++++++++++++++++++++++++++
>  tests/qemu-iotests/group   |   1 +
>  3 files changed, 224 insertions(+)
>  create mode 100755 tests/qemu-iotests/100
>  create mode 100644 tests/qemu-iotests/100.out
> 

> +echo "== Superset overlapping requests =="
> +_make_test_img $size
> +$QEMU_IO -c "multiwrite 0 4k ; 1k 2k" "$TEST_IMG" | _filter_qemu_io
> +
> +echo
> +echo "== verify pattern =="
> +# Order of overlapping in-flight requests is not guaranteed so we cannot 
> verify
> +# [1k, 3k) since it could have either pattern 0xcd or 0xce.
> +$QEMU_IO -c "read -P 0xcd 0 1k" "$TEST_IMG" | _filter_qemu_io
> +$QEMU_IO -c "read -P 0xcd 3k 1k" "$TEST_IMG" | _filter_qemu_io
> +$QEMU_IO -c "read -P 0 4k 4k" "$TEST_IMG" | _filter_qemu_io

I agree that we can't guarantee whether the first or the second write
requested ended up in [1k, 3k).  But can we enhance 'read' to allow one
or two new modes, so that we can do a test that no 0 bytes remain in the
region (all bytes were written), and/or do a test that all bytes in the
region have the same (unknown) value (we don't know whether A or B
finished first, but all bytes written came from the same job that
finished last)?  If we had such a verification mode, you could use it
here and in all the remaining tests where you skipped verification
because of not knowing which byte would be present.

But I would also be okay with enhancing 'read' as a followup patch, so:

Reviewed-by: Eric Blake <address@hidden>

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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