1. Patchew
  2. QEMU
  3. [Qemu-devel] [PATCH 0/9] nbd block status base:allocation
  4. View patch

[Qemu-devel] [PATCH 9/9] iotests: new test 206 for NBD BLOCK_STATUS

Vladimir Sementsov-Ogievskiy posted 9 patches 7 years, 8 months ago
There is a newer version of this series
[Qemu-devel] [PATCH 9/9] iotests: new test 206 for NBD BLOCK_STATUS
Posted by Vladimir Sementsov-Ogievskiy 7 years, 8 months ago 
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
---
 tests/qemu-iotests/206     | 34 ++++++++++++++++++++++++++++++++++
 tests/qemu-iotests/206.out |  2 ++
 tests/qemu-iotests/group   |  1 +
 3 files changed, 37 insertions(+)
 create mode 100644 tests/qemu-iotests/206
 create mode 100644 tests/qemu-iotests/206.out

diff --git a/tests/qemu-iotests/206 b/tests/qemu-iotests/206
new file mode 100644
index 0000000000..259e991ec6
--- /dev/null
+++ b/tests/qemu-iotests/206
@@ -0,0 +1,34 @@
+#!/usr/bin/env python
+#
+# Tests for NBD BLOCK_STATUS extension
+#
+# Copyright (c) 2018 Virtuozzo International GmbH
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+#
+
+import iotests
+from iotests import qemu_img_create, qemu_io, qemu_img_verbose, qemu_nbd, \
+                    file_path
+
+iotests.verify_image_format(supported_fmts=['qcow2'])
+
+disk, nbd_sock = file_path('disk', 'nbd-sock')
+nbd_uri = 'nbd+unix:///exp?socket=' + nbd_sock
+
+qemu_img_create('-f', iotests.imgfmt, disk, '1M')
+qemu_io('-f', iotests.imgfmt, '-c', 'write 0 512K', disk)
+
+qemu_nbd('-k', nbd_sock, '-x', 'exp', '-f', iotests.imgfmt, disk)
+qemu_img_verbose('map', '-f', 'raw', '--output=json', nbd_uri)
diff --git a/tests/qemu-iotests/206.out b/tests/qemu-iotests/206.out
new file mode 100644
index 0000000000..0d29724e84
--- /dev/null
+++ b/tests/qemu-iotests/206.out
@@ -0,0 +1,2 @@
+[{ "start": 0, "length": 524288, "depth": 0, "zero": false, "data": true},
+{ "start": 524288, "length": 524288, "depth": 0, "zero": true, "data": false}]
diff --git a/tests/qemu-iotests/group b/tests/qemu-iotests/group
index a2dfe79d86..2c3925566a 100644
--- a/tests/qemu-iotests/group
+++ b/tests/qemu-iotests/group
@@ -202,3 +202,4 @@
 203 rw auto
 204 rw auto quick
 205 rw auto quick
+206 rw auto quick
-- 
2.11.1
Re: [Qemu-devel] [PATCH 9/9] iotests: new test 206 for NBD BLOCK_STATUS
Posted by Eric Blake 7 years, 8 months ago 
On 02/15/2018 07:51 AM, Vladimir Sementsov-Ogievskiy wrote:
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> ---
>   tests/qemu-iotests/206     | 34 ++++++++++++++++++++++++++++++++++
>   tests/qemu-iotests/206.out |  2 ++
>   tests/qemu-iotests/group   |  1 +
>   3 files changed, 37 insertions(+)
>   create mode 100644 tests/qemu-iotests/206
>   create mode 100644 tests/qemu-iotests/206.out

It's a race! Kevin already has test 206 and 207 claimed in his pending 
series:
https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg02363.html
Whoever loses gets to rebase and renumber (or the maintainer on their 
behalf) ;)

> 
> diff --git a/tests/qemu-iotests/206 b/tests/qemu-iotests/206
> new file mode 100644

Oops, you forgot to mark this executable.  And oops, I forgot to flag 
that on test 205.  Other inconsistent tests: 096, 124, 129, 132, 136, 
139, 148, 152, 163. Separate cleanup patch coming up soon.

> index 0000000000..259e991ec6
> --- /dev/null
> +++ b/tests/qemu-iotests/206
> @@ -0,0 +1,34 @@
> +#!/usr/bin/env python
> +#
> +# Tests for NBD BLOCK_STATUS extension
> +#

> +import iotests
> +from iotests import qemu_img_create, qemu_io, qemu_img_verbose, qemu_nbd, \
> +                    file_path
> +
> +iotests.verify_image_format(supported_fmts=['qcow2'])

Don't we also need to blacklist v2 files (and only operate on v3 or 
newer), since the behavior of zero clusters is much worse on v2 images?

> +
> +disk, nbd_sock = file_path('disk', 'nbd-sock')
> +nbd_uri = 'nbd+unix:///exp?socket=' + nbd_sock
> +
> +qemu_img_create('-f', iotests.imgfmt, disk, '1M')
> +qemu_io('-f', iotests.imgfmt, '-c', 'write 0 512K', disk)

Hopefully large enough for all the major filesystems with sparse support 
to show half-data, half-hole, and not run into any weird issues where 
granularity differences between filesystems change the outcome.

> +
> +qemu_nbd('-k', nbd_sock, '-x', 'exp', '-f', iotests.imgfmt, disk)
> +qemu_img_verbose('map', '-f', 'raw', '--output=json', nbd_uri)
> diff --git a/tests/qemu-iotests/206.out b/tests/qemu-iotests/206.out
> new file mode 100644
> index 0000000000..0d29724e84
> --- /dev/null
> +++ b/tests/qemu-iotests/206.out
> @@ -0,0 +1,2 @@
> +[{ "start": 0, "length": 524288, "depth": 0, "zero": false, "data": true},
> +{ "start": 524288, "length": 524288, "depth": 0, "zero": true, "data": false}]

But definite evidence of getting block status over NBD! Progress!

And kudos for producing an .out file that I can actually read and 
reproduce without the aid of python (in contrast to the more 
"unit-test"-y ones like 205, where we had a big long side-discussion 
about that. No need to repeat it here).

> diff --git a/tests/qemu-iotests/group b/tests/qemu-iotests/group
> index a2dfe79d86..2c3925566a 100644
> --- a/tests/qemu-iotests/group
> +++ b/tests/qemu-iotests/group
> @@ -202,3 +202,4 @@
>   203 rw auto
>   204 rw auto quick
>   205 rw auto quick
> +206 rw auto quick
> 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org
Re: [Qemu-devel] [PATCH 9/9] iotests: new test 206 for NBD BLOCK_STATUS
Posted by Vladimir Sementsov-Ogievskiy 7 years, 7 months ago 
17.02.2018 00:02, Eric Blake wrote:
> On 02/15/2018 07:51 AM, Vladimir Sementsov-Ogievskiy wrote:
>> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
>> ---
>>   tests/qemu-iotests/206     | 34 ++++++++++++++++++++++++++++++++++
>>   tests/qemu-iotests/206.out |  2 ++
>>   tests/qemu-iotests/group   |  1 +
>>   3 files changed, 37 insertions(+)
>>   create mode 100644 tests/qemu-iotests/206
>>   create mode 100644 tests/qemu-iotests/206.out
>
> It's a race! Kevin already has test 206 and 207 claimed in his pending 
> series:
> https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg02363.html
> Whoever loses gets to rebase and renumber (or the maintainer on their 
> behalf) ;)


is there any simple method to get a number for new test? Any way to 
avoid such situations?

>
>>
>> diff --git a/tests/qemu-iotests/206 b/tests/qemu-iotests/206
>> new file mode 100644
>
> Oops, you forgot to mark this executable.  And oops, I forgot to flag 
> that on test 205.  Other inconsistent tests: 096, 124, 129, 132, 136, 
> 139, 148, 152, 163. Separate cleanup patch coming up soon.
>
>> index 0000000000..259e991ec6
>> --- /dev/null
>> +++ b/tests/qemu-iotests/206
>> @@ -0,0 +1,34 @@
>> +#!/usr/bin/env python
>> +#
>> +# Tests for NBD BLOCK_STATUS extension
>> +#
>
>> +import iotests
>> +from iotests import qemu_img_create, qemu_io, qemu_img_verbose, 
>> qemu_nbd, \
>> +                    file_path
>> +
>> +iotests.verify_image_format(supported_fmts=['qcow2'])
>
> Don't we also need to blacklist v2 files (and only operate on v3 or 
> newer), since the behavior of zero clusters is much worse on v2 images?

hm. I think if test passed, all is ok. qemu-img creates good enough 
image to pass the test..

>
>> +
>> +disk, nbd_sock = file_path('disk', 'nbd-sock')
>> +nbd_uri = 'nbd+unix:///exp?socket=' + nbd_sock
>> +
>> +qemu_img_create('-f', iotests.imgfmt, disk, '1M')
>> +qemu_io('-f', iotests.imgfmt, '-c', 'write 0 512K', disk)
>
> Hopefully large enough for all the major filesystems with sparse 
> support to show half-data, half-hole, and not run into any weird 
> issues where granularity differences between filesystems change the 
> outcome.
>
>> +
>> +qemu_nbd('-k', nbd_sock, '-x', 'exp', '-f', iotests.imgfmt, disk)
>> +qemu_img_verbose('map', '-f', 'raw', '--output=json', nbd_uri)
>> diff --git a/tests/qemu-iotests/206.out b/tests/qemu-iotests/206.out
>> new file mode 100644
>> index 0000000000..0d29724e84
>> --- /dev/null
>> +++ b/tests/qemu-iotests/206.out
>> @@ -0,0 +1,2 @@
>> +[{ "start": 0, "length": 524288, "depth": 0, "zero": false, "data": 
>> true},
>> +{ "start": 524288, "length": 524288, "depth": 0, "zero": true, 
>> "data": false}]
>
> But definite evidence of getting block status over NBD! Progress!
>
> And kudos for producing an .out file that I can actually read and 
> reproduce without the aid of python (in contrast to the more 
> "unit-test"-y ones like 205, where we had a big long side-discussion 
> about that. No need to repeat it here).
>
>> diff --git a/tests/qemu-iotests/group b/tests/qemu-iotests/group
>> index a2dfe79d86..2c3925566a 100644
>> --- a/tests/qemu-iotests/group
>> +++ b/tests/qemu-iotests/group
>> @@ -202,3 +202,4 @@
>>   203 rw auto
>>   204 rw auto quick
>>   205 rw auto quick
>> +206 rw auto quick
>>
>


-- 
Best regards,
Vladimir
Re: [Qemu-devel] [PATCH 9/9] iotests: new test 206 for NBD BLOCK_STATUS
Posted by Eric Blake 7 years, 7 months ago 
On 03/01/2018 05:51 AM, Vladimir Sementsov-Ogievskiy wrote:
> 17.02.2018 00:02, Eric Blake wrote:
>> On 02/15/2018 07:51 AM, Vladimir Sementsov-Ogievskiy wrote:
>>> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
>>> ---
>>>   tests/qemu-iotests/206     | 34 ++++++++++++++++++++++++++++++++++
>>>   tests/qemu-iotests/206.out |  2 ++
>>>   tests/qemu-iotests/group   |  1 +
>>>   3 files changed, 37 insertions(+)
>>>   create mode 100644 tests/qemu-iotests/206
>>>   create mode 100644 tests/qemu-iotests/206.out
>>
>> It's a race! Kevin already has test 206 and 207 claimed in his pending 
>> series:
>> https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg02363.html
>> Whoever loses gets to rebase and renumber (or the maintainer on their 
>> behalf) ;)
> 
> 
> is there any simple method to get a number for new test? Any way to 
> avoid such situations?

Short of searching the mailing list for what numbers have already been 
mentioned, not really.

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

Patchew 2.1-devel-b67e4c2

© 2016 - 2025 Red Hat, Inc.