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

2018-03-01 Thread Eric Blake 

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 
---
  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

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

2018-03-01 Thread Vladimir Sementsov-Ogievskiy 

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 
---
  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 00..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 00..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-block] [PATCH 9/9] iotests: new test 206 for NBD BLOCK_STATUS

2018-02-16 Thread Eric Blake 

On 02/15/2018 07:51 AM, Vladimir Sementsov-Ogievskiy wrote:

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
  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 00..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 00..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