Re: [Qemu-devel] [PATCH 2/2] qemu-iotests: Test progress output for conversion

[Kevin Wolf]

Am 03.03.2014 um 19:20 hat Eric Blake geschrieben:
> On 03/03/2014 06:57 AM, Kevin Wolf wrote:
> > Signed-off-by: Kevin Wolf <address@hidden>
> > ---
> >  tests/qemu-iotests/086     | 65 
> > ++++++++++++++++++++++++++++++++++++++++++++++
> >  tests/qemu-iotests/086.out | 18 +++++++++++++
> >  tests/qemu-iotests/group   |  1 +
> >  3 files changed, 84 insertions(+)
> >  create mode 100755 tests/qemu-iotests/086
> >  create mode 100644 tests/qemu-iotests/086.out
> > 
> 
> > +
> > +$QEMU_IMG convert -p -O $IMGFMT -f $IMGFMT "$TEST_IMG" "$TEST_IMG".base  
> > 2>&1 |\
> > +    _filter_testdir | sed -e 's/\r/\n/g'
> 
> \r is not portable sed.  Alas, coming up with a portable way to
> represent carriage return in sed is a bear, so I can live with this
> reliance on GNU sed.

We already have it in other places, so I guess this one doesn't make
things worse.

> > +wrote 1048576/1048576 bytes at offset 33554432
> > +1 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> > +    (0.00/100%)
> > +    (25.00/100%)
> > +    (50.00/100%)
> > +    (75.00/100%)
> > +    (100.00/100%)
> > +    (100.00/100%)
> 
> Feels fragile (will it ALWAYS be done in chunks of 25% completion?) but
> if it passes reliably, it's always better to have more test coverage.

Yes, this concern is what stopped me from writing such a test for a long
time. However, I think we really need a test case for it because
apparently we tend to break this, and after some pondering I came to the
conclusion that results should be consistent as long as we restrict it
to a single image format (drivers may behave differently), which is not
raw (that would expose filesystem-specific behaviour).

With a qcow2-only case I think we should be fine as long as neither
qcow2 nor qemu-img change their implementation.

The other case that I would love to test is not specifying -p but
sending SIGUSR1. I'm not sure how to do that in a consistent way,
though. Perhaps something with blkdebug.

> Can we test the other commands that support -p?  And is anyone
> interested in adding -p support to more commands (there are several
> long-running commands that could use it but don't have it yet).

Feel free to implement it. ;-)

(Perhaps it would be easier after converting some qemu-img subcommands
to use block jobs internally.)

Kevin

pgpUrvKvSTFKw.pgp
Description: PGP signature