1 files changed, 80 insertions, 0 deletions
diff --git a/results/classifier/118/none/603872 b/results/classifier/118/none/603872
new file mode 100644
index 00000000..5c9e764e
--- /dev/null
+++ b/results/classifier/118/none/603872
@@ -0,0 +1,80 @@
+performance: 0.720
+graphic: 0.657
+device: 0.632
+PID: 0.576
+ppc: 0.544
+architecture: 0.526
+vnc: 0.521
+arm: 0.492
+hypervisor: 0.478
+files: 0.477
+semantic: 0.467
+VMM: 0.465
+network: 0.452
+i386: 0.431
+TCG: 0.421
+KVM: 0.418
+x86: 0.417
+kernel: 0.415
+user-level: 0.392
+debug: 0.371
+register: 0.369
+peripherals: 0.361
+assembly: 0.341
+permissions: 0.328
+socket: 0.326
+mistranslation: 0.319
+risc-v: 0.308
+virtual: 0.252
+boot: 0.237
+
+[Feature request] qemu-img image conversion does not show percentage
+
+It will be nice if qemu-img will be able to show percentage of completition and average speed of conversion and compress ratio (if converting to compressed qcow or qcow2)
+
+qemu-img convert -p does show a percentage completion (but not avg speed or compression ratio) so this is at least partially done.
+
+Incomplete patch.
+
+Usecase: `qemu-img convert` with -p now shows the write speed.
+
+1. I'm calculating the speed using the time taken to run the for(;;)
+at qemu-img.c:1477. I figured that every time this loop runs, n1
+sectors are converted, and so I calculate the write_speed
+accordingly. Is this correct?
+
+2. I have changed qemu-progress.c:qemu_progress_print() to take in a
+speed parameter, thinking that it would be the best option. Should I
+do it some other way instead (maybe write another function to print
+just speed)?
+
+On Mon, Nov 18, 2013 at 03:55:45PM -0000, Varad wrote:
+> Incomplete patch.
+> 
+> Usecase: `qemu-img convert` with -p now shows the write speed.
+> 
+> 1. I'm calculating the speed using the time taken to run the for(;;)
+> at qemu-img.c:1477. I figured that every time this loop runs, n1
+> sectors are converted, and so I calculate the write_speed
+> accordingly. Is this correct?
+> 
+> 2. I have changed qemu-progress.c:qemu_progress_print() to take in a
+> speed parameter, thinking that it would be the best option. Should I
+> do it some other way instead (maybe write another function to print
+> just speed)?
+> 
+> ** Patch added: "[PATCH/RFC]"
+>    https://bugs.launchpad.net/qemu/+bug/603872/+attachment/3911803/+files/0001-qemu-img-show-image-conversion-speed.patch
+
+Patches attached on the bug tracker are not reviewed, they should be
+sent to the qemu-devel mailing list instead.
+
+If you want to link to a submitted patch from launchpad, please post a
+mailing list archive link.  For example:
+http://article.gmane.org/gmane.comp.emulators.qemu/242109
+
+
+Progress printing had been added here:
+https://gitlab.com/qemu-project/qemu/-/commit/6b837bc4a4d
+So I think it should be fine to close this ticket now.
+