qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 33/34] qemu-iotests: Test cache mode option inhe


From: Max Reitz
Subject: Re: [Qemu-devel] [PATCH 33/34] qemu-iotests: Test cache mode option inheritance
Date: Mon, 18 May 2015 17:32:02 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

On 18.05.2015 16:39, Kevin Wolf wrote:
Am 15.05.2015 um 21:16 hat Max Reitz geschrieben:
On 08.05.2015 19:22, Kevin Wolf wrote:
This is doing a more complete test on setting cache modes both while
opening an image (i.e. in a -drive command line) and in reopen
situations. It checks that reopen can specify options for child nodes
and that cache modes are correctly inherited from parent nodes where
they are not specified.

Signed-off-by: Kevin Wolf <address@hidden>
---
  tests/qemu-iotests/132     | 336 ++++++++++++++++++++
  tests/qemu-iotests/132.out | 767 +++++++++++++++++++++++++++++++++++++++++++++
  tests/qemu-iotests/group   |   1 +
  3 files changed, 1104 insertions(+)
  create mode 100755 tests/qemu-iotests/132
  create mode 100644 tests/qemu-iotests/132.out

So starting from now I once again need to specify -c writethrough
for running tests in tmpfs... Welp.

("Welp" because there is no actual strict requirement to have
O_DIRECT, because we don't actually use it but only check the
configuration; so using null-co would be fine, too, but we can only
use that with raw as the format driver, and raw doesn't support
backing files...)
Perhaps we should add a switch to tell qemu-iotests to skip test cases
that would require cache.direct=on? Or create a group 'direct' so you
can use '-x direct'?

Well, it would be 'non-direct', and in this case it's not better than -c writethrough. ;-)

I was lucky I got away without specifying the cache mode until now, and now I'll just have to live with it. If we (I) would want to make it easier, we'd have to probe (in ./check) whether $TEST_DIR supports O_DIRECT or not.

Max



reply via email to

[Prev in Thread] Current Thread [Next in Thread]