On 5/20/20 7:50 AM, Richard W.M. Jones wrote:
The old test relied on issuing an asynchronous command to a qemu-io
subprocess, requiring a sleep to ensure that the command had been
carried out.  ‘sleep 1’ was not long enough on s390x as you can see
from this partial trace:

Nice analysis.

Here are still connecting to nbdkit from "connection A", long after
the sleep has finished and the truncate has been done.

Instead of increasing the sleep and hoping for the best, I chose to
rewrite the test to use nbdsh.  This allows us to control both
connections from a single process, making the test predicatable and
easier to understand.

Indeed. nbdsh is making a lot of tests easier to write, and it is now just a question of revisiting the older tests that predated it.

---
  tests/test-truncate4.sh | 90 ++++++++++++++++++++++++++---------------
  1 file changed, 58 insertions(+), 32 deletions(-)

diff --git a/tests/test-truncate4.sh b/tests/test-truncate4.sh
index e4be626b..c5dc608c 100755
--- a/tests/test-truncate4.sh
+++ b/tests/test-truncate4.sh

-requires qemu-io --version
+requires nbdsh --version
+requires truncate --help

We probably don't need truncate...

+
+if ! dd --help | grep fullblock; then
+    echo "$0: requires GNU dd with the iflag=fullblock option"
+    exit 77
+fi
sock=`mktemp -u`
-files="truncate4.out truncate4.pid $sock truncate4.data"
+data=truncate4.data
+files="truncate4.pid $sock $data"
  rm -f $files
  cleanup_fn rm -f $files
-# Initial file contents: 1k of pattern 1
-truncate -s 1024 truncate4.data
-qemu-io -c 'w -P 1 0 1024' -f raw truncate4.data
+truncate -s 0 $data

...true, the old code used it (without requiring it!), but in the new code, you could get away with ': > $data' instead of having to invoke truncate. Then where the old code resized the file with truncate between connections A and B, the new code is using python.

The conversion itself looks correct to me.  ACK.

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

_______________________________________________
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

Reply via email to