qemu/tests/qemu-iotests/093.out

..........
----------------------------------------------------------------------
Ran 10 tests

OK
qemu-iotests: Test removing a throttle group member with a pending timer A throttle group can have several members, and each one of them can have several pending requests in the queue. The requests are processed in a round-robin fashion, so the algorithm decides the drive that is going to run the next request and sets a timer in it. Once the timer fires and the throttled request is run then the next drive from the group is selected and a new timer is set. If the user tried to remove a drive from a group and that drive had a timer set then the code was not taking care of setting up a new timer in one of the remaining members of the group, freezing their I/O. This problem was fixed in 6fccbb475bc6effc313ee9481726a1748b6dae57, and this patch adds a new test case that reproduces this exact scenario. Signed-off-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> 2018-08-02 17:50:23 +03:00			`..........`
qemu-iotests: Add 093 for IO throttling This case utilizes qemu-io command "aio_{read,write} -q" to verify the effectiveness of IO throttling options. It's implemented by driving the vm timer from qtest protocol, so the throttling timers are signaled with determinied time duration. Then we verify the completed IO requests are within 10% error of bps and iops limits. "null" protocol is used as the disk backend so that no actual disk IO is performed on host, this will make the blockstats much more deterministic. Both "null-aio" and "null-co" are covered, which is also a simple cross validation test for the driver code. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Message-id: 1422586186-9925-6-git-send-email-famz@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> 2015-01-30 05:49:46 +03:00			`----------------------------------------------------------------------`
qemu-iotests: Test removing a throttle group member with a pending timer A throttle group can have several members, and each one of them can have several pending requests in the queue. The requests are processed in a round-robin fashion, so the algorithm decides the drive that is going to run the next request and sets a timer in it. Once the timer fires and the throttled request is run then the next drive from the group is selected and a new timer is set. If the user tried to remove a drive from a group and that drive had a timer set then the code was not taking care of setting up a new timer in one of the remaining members of the group, freezing their I/O. This problem was fixed in 6fccbb475bc6effc313ee9481726a1748b6dae57, and this patch adds a new test case that reproduces this exact scenario. Signed-off-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> 2018-08-02 17:50:23 +03:00			`Ran 10 tests`
qemu-iotests: Add 093 for IO throttling This case utilizes qemu-io command "aio_{read,write} -q" to verify the effectiveness of IO throttling options. It's implemented by driving the vm timer from qtest protocol, so the throttling timers are signaled with determinied time duration. Then we verify the completed IO requests are within 10% error of bps and iops limits. "null" protocol is used as the disk backend so that no actual disk IO is performed on host, this will make the blockstats much more deterministic. Both "null-aio" and "null-co" are covered, which is also a simple cross validation test for the driver code. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Message-id: 1422586186-9925-6-git-send-email-famz@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> 2015-01-30 05:49:46 +03:00
			`OK`