OpenE2K
/
qemu-e2k
13
4
Fork 0
Code Issues 4 Pull Requests Projects 2 Releases Activity
qemu-e2k/tests/qemu-iotests/142.out

769 lines
27 KiB
Plaintext
Raw Normal View History

qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
QA output created by 142
Formatting 'TEST_DIR/t.IMGFMT.base', fmt=IMGFMT size=134217728
Formatting 'TEST_DIR/t.IMGFMT.snap', fmt=IMGFMT size=134217728
iotests: Specify explicit backing format where sensible There are many existing qcow2 images that specify a backing file but no format. This has been the source of CVEs in the past, but has become more prominent of a problem now that libvirt has switched to -blockdev. With older -drive, at least the probing was always done by qemu (so the only risk of a changed format between successive boots of a guest was if qemu was upgraded and probed differently). But with newer -blockdev, libvirt must specify a format; if libvirt guesses raw where the image was formatted, this results in data corruption visible to the guest; conversely, if libvirt guesses qcow2 where qemu was using raw, this can result in potential security holes, so modern libvirt instead refuses to use images without explicit backing format. The change in libvirt to reject images without explicit backing format has pointed out that a number of tools have been far too reliant on probing in the past. It's time to set a better example in our own iotests of properly setting this parameter. iotest calls to create, rebase, and convert are all impacted to some degree. It's a bit annoying that we are inconsistent on command line - while all of those accept -o backing_file=...,backing_fmt=..., the shortcuts are different: create and rebase have -b and -F, while convert has -B but no -F. (amend has no shortcuts, but the previous patch just deprecated the use of amend to change backing chains). Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20200706203954.341758-9-eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-06 22:39:52 +02:00
Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728 backing_file=TEST_DIR/t.IMGFMT.base backing_fmt=IMGFMT
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
=== Simple test for all cache modes ===
Testing: -drive file=TEST_DIR/t.qcow2,cache=none
QEMU X.Y.Z monitor - type 'help' for more information
qemu-iotests: Filter HMP readline escape characters The only thing the escape characters achieve is making the reference output unreadable and lines that are potentially so long that git doesn't want to put them into an email any more. Let's filter them out. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2017-04-13 19:19:51 +02:00
(qemu) quit
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Testing: -drive file=TEST_DIR/t.qcow2,cache=directsync
QEMU X.Y.Z monitor - type 'help' for more information
qemu-iotests: Filter HMP readline escape characters The only thing the escape characters achieve is making the reference output unreadable and lines that are potentially so long that git doesn't want to put them into an email any more. Let's filter them out. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2017-04-13 19:19:51 +02:00
(qemu) quit
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Testing: -drive file=TEST_DIR/t.qcow2,cache=writeback
QEMU X.Y.Z monitor - type 'help' for more information
qemu-iotests: Filter HMP readline escape characters The only thing the escape characters achieve is making the reference output unreadable and lines that are potentially so long that git doesn't want to put them into an email any more. Let's filter them out. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2017-04-13 19:19:51 +02:00
(qemu) quit
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Testing: -drive file=TEST_DIR/t.qcow2,cache=writethrough
QEMU X.Y.Z monitor - type 'help' for more information
qemu-iotests: Filter HMP readline escape characters The only thing the escape characters achieve is making the reference output unreadable and lines that are potentially so long that git doesn't want to put them into an email any more. Let's filter them out. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2017-04-13 19:19:51 +02:00
(qemu) quit
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Testing: -drive file=TEST_DIR/t.qcow2,cache=unsafe
QEMU X.Y.Z monitor - type 'help' for more information
qemu-iotests: Filter HMP readline escape characters The only thing the escape characters achieve is making the reference output unreadable and lines that are potentially so long that git doesn't want to put them into an email any more. Let's filter them out. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2017-04-13 19:19:51 +02:00
(qemu) quit
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Testing: -drive file=TEST_DIR/t.qcow2,cache=invalid_value
QEMU_PROG: -drive file=TEST_DIR/t.qcow2,cache=invalid_value: invalid cache option
=== Check inheritance of cache modes ===
--- Configure cache modes on the command line ---
cache.direct=on on none0
Cache mode: writeback, direct
Cache mode: writeback, direct
Cache mode: writeback, direct
Cache mode: writeback, direct
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback, direct
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
cache.direct=on on file
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Cache mode: writeback
Cache mode: writeback, direct
Cache mode: writeback
Cache mode: writeback
cache.direct=on on backing
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback, direct
Cache mode: writeback, direct
cache.direct=on on backing-file
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Cache mode: writeback, direct
cache.writeback=off on none0
Cache mode: writethrough
Cache mode: writeback
block: Make backing files always writeback First of all, we're generally not writing to backing files, but when we do, it's in the context of block jobs which know very well when to flush the image. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2016-03-04 14:52:32 +01:00
Cache mode: writeback
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Cache mode: writeback
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
cache.writeback=off on file
block: Remove BDRV_O_CACHE_WB The previous patches have successively made blk->enable_write_cache the true source for the information whether a writethrough mode must be implemented. The corresponding BDRV_O_CACHE_WB is only useless baggage we're carrying around, so now's the time to remove it. At the same time, we remove the 'cache.writeback' option parsing on the BDS level as the only effect was setting the BDRV_O_CACHE_WB flag. This change requires test cases that explicitly enabled the option to drop it. Other than that and the change of the error message when writethrough is enabled on the BDS level (from "Can't set writethrough mode" to "doesn't support the option"), there should be no change in behaviour. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-18 17:46:45 +01:00
QEMU_PROG: -drive if=none,file=TEST_DIR/t.qcow2,backing.file.filename=TEST_DIR/t.qcow2.base,node-name=image,backing.node-name=backing,backing.file.node-name=backing-file,file.node-name=file,file.cache.writeback=off: Block protocol 'file' doesn't support the option 'cache.writeback'
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
cache.writeback=off on backing
block: Remove BDRV_O_CACHE_WB The previous patches have successively made blk->enable_write_cache the true source for the information whether a writethrough mode must be implemented. The corresponding BDRV_O_CACHE_WB is only useless baggage we're carrying around, so now's the time to remove it. At the same time, we remove the 'cache.writeback' option parsing on the BDS level as the only effect was setting the BDRV_O_CACHE_WB flag. This change requires test cases that explicitly enabled the option to drop it. Other than that and the change of the error message when writethrough is enabled on the BDS level (from "Can't set writethrough mode" to "doesn't support the option"), there should be no change in behaviour. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-18 17:46:45 +01:00
QEMU_PROG: -drive if=none,file=TEST_DIR/t.qcow2,backing.file.filename=TEST_DIR/t.qcow2.base,node-name=image,backing.node-name=backing,backing.file.node-name=backing-file,file.node-name=file,backing.cache.writeback=off: Could not open backing file: Block format 'qcow2' does not support the option 'cache.writeback'
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
cache.writeback=off on backing-file
block: Remove BDRV_O_CACHE_WB The previous patches have successively made blk->enable_write_cache the true source for the information whether a writethrough mode must be implemented. The corresponding BDRV_O_CACHE_WB is only useless baggage we're carrying around, so now's the time to remove it. At the same time, we remove the 'cache.writeback' option parsing on the BDS level as the only effect was setting the BDRV_O_CACHE_WB flag. This change requires test cases that explicitly enabled the option to drop it. Other than that and the change of the error message when writethrough is enabled on the BDS level (from "Can't set writethrough mode" to "doesn't support the option"), there should be no change in behaviour. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-18 17:46:45 +01:00
QEMU_PROG: -drive if=none,file=TEST_DIR/t.qcow2,backing.file.filename=TEST_DIR/t.qcow2.base,node-name=image,backing.node-name=backing,backing.file.node-name=backing-file,file.node-name=file,backing.file.cache.writeback=off: Could not open backing file: Block protocol 'file' doesn't support the option 'cache.writeback'
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
cache.no-flush=on on none0
Cache mode: writeback, ignore flushes
Cache mode: writeback, ignore flushes
Cache mode: writeback, ignore flushes
Cache mode: writeback, ignore flushes
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback, ignore flushes
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
cache.no-flush=on on file
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Cache mode: writeback
Cache mode: writeback, ignore flushes
Cache mode: writeback
Cache mode: writeback
cache.no-flush=on on backing
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback, ignore flushes
Cache mode: writeback, ignore flushes
cache.no-flush=on on backing-file
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Cache mode: writeback, ignore flushes
--- Cache modes after reopen (live snapshot) ---
cache.direct=on on none0
Cache mode: writeback, direct
Cache mode: writeback, direct
Cache mode: writeback, direct
Cache mode: writeback, direct
Cache mode: writeback, direct
cache.direct=on on file
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback, direct
Cache mode: writeback
Cache mode: writeback
cache.direct=on on backing
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback, direct
Cache mode: writeback, direct
cache.direct=on on backing-file
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback, direct
cache.writeback=off on none0
Cache mode: writethrough
block: Move enable_write_cache to BB level Whether a write cache is used or not is a decision that concerns the user (e.g. the guest device) rather than the backend. It was already logically part of the BB level as bdrv_move_feature_fields() always kept it on top of the BDS tree; with this patch, the core of it (the actual flag and the additional flushes) is also implemented there. Direct callers of bdrv_open() must pass BDRV_O_CACHE_WB now if bs doesn't have a BlockBackend attached. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-04 14:28:01 +01:00
Cache mode: writeback
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Cache mode: writeback
block: Make backing files always writeback First of all, we're generally not writing to backing files, but when we do, it's in the context of block jobs which know very well when to flush the image. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2016-03-04 14:52:32 +01:00
Cache mode: writeback
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Cache mode: writeback
cache.writeback=off on file
block: Remove BDRV_O_CACHE_WB The previous patches have successively made blk->enable_write_cache the true source for the information whether a writethrough mode must be implemented. The corresponding BDRV_O_CACHE_WB is only useless baggage we're carrying around, so now's the time to remove it. At the same time, we remove the 'cache.writeback' option parsing on the BDS level as the only effect was setting the BDRV_O_CACHE_WB flag. This change requires test cases that explicitly enabled the option to drop it. Other than that and the change of the error message when writethrough is enabled on the BDS level (from "Can't set writethrough mode" to "doesn't support the option"), there should be no change in behaviour. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-18 17:46:45 +01:00
QEMU_PROG: -drive if=none,file=TEST_DIR/t.qcow2,backing.file.filename=TEST_DIR/t.qcow2.base,node-name=image,backing.node-name=backing,backing.file.node-name=backing-file,file.node-name=file,file.cache.writeback=off: Block protocol 'file' doesn't support the option 'cache.writeback'
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
cache.writeback=off on backing
block: Remove BDRV_O_CACHE_WB The previous patches have successively made blk->enable_write_cache the true source for the information whether a writethrough mode must be implemented. The corresponding BDRV_O_CACHE_WB is only useless baggage we're carrying around, so now's the time to remove it. At the same time, we remove the 'cache.writeback' option parsing on the BDS level as the only effect was setting the BDRV_O_CACHE_WB flag. This change requires test cases that explicitly enabled the option to drop it. Other than that and the change of the error message when writethrough is enabled on the BDS level (from "Can't set writethrough mode" to "doesn't support the option"), there should be no change in behaviour. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-18 17:46:45 +01:00
QEMU_PROG: -drive if=none,file=TEST_DIR/t.qcow2,backing.file.filename=TEST_DIR/t.qcow2.base,node-name=image,backing.node-name=backing,backing.file.node-name=backing-file,file.node-name=file,backing.cache.writeback=off: Could not open backing file: Block format 'qcow2' does not support the option 'cache.writeback'
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
cache.writeback=off on backing-file
block: Remove BDRV_O_CACHE_WB The previous patches have successively made blk->enable_write_cache the true source for the information whether a writethrough mode must be implemented. The corresponding BDRV_O_CACHE_WB is only useless baggage we're carrying around, so now's the time to remove it. At the same time, we remove the 'cache.writeback' option parsing on the BDS level as the only effect was setting the BDRV_O_CACHE_WB flag. This change requires test cases that explicitly enabled the option to drop it. Other than that and the change of the error message when writethrough is enabled on the BDS level (from "Can't set writethrough mode" to "doesn't support the option"), there should be no change in behaviour. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-18 17:46:45 +01:00
QEMU_PROG: -drive if=none,file=TEST_DIR/t.qcow2,backing.file.filename=TEST_DIR/t.qcow2.base,node-name=image,backing.node-name=backing,backing.file.node-name=backing-file,file.node-name=file,backing.file.cache.writeback=off: Could not open backing file: Block protocol 'file' doesn't support the option 'cache.writeback'
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
cache.no-flush=on on none0
Cache mode: writeback, ignore flushes
Cache mode: writeback, ignore flushes
Cache mode: writeback, ignore flushes
Cache mode: writeback, ignore flushes
Cache mode: writeback, ignore flushes
cache.no-flush=on on file
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback, ignore flushes
Cache mode: writeback
Cache mode: writeback
cache.no-flush=on on backing
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback, ignore flushes
Cache mode: writeback, ignore flushes
cache.no-flush=on on backing-file
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback, ignore flushes
--- Change cache modes with reopen (qemu-io command, flags) ---
cache.direct=on on none0
Cache mode: writeback, direct
Cache mode: writeback, direct
Cache mode: writeback, direct
Cache mode: writeback, direct
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback, direct
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
cache.direct=on on file
Cache mode: writeback, direct
Cache mode: writeback, direct
Cache mode: writeback, direct
Cache mode: writeback, direct
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback, direct
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
cache.direct=on on backing
Cache mode: writeback, direct
Cache mode: writeback, direct
Cache mode: writeback, direct
Cache mode: writeback, direct
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback, direct
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
cache.direct=on on backing-file
Cache mode: writeback, direct
Cache mode: writeback, direct
Cache mode: writeback, direct
Cache mode: writeback, direct
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback, direct
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
cache.writeback=off on none0
Cache mode: writeback, direct
Cache mode: writeback, direct
Cache mode: writeback, direct
Cache mode: writeback, direct
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback, direct
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
cache.writeback=off on file
block: Remove BDRV_O_CACHE_WB The previous patches have successively made blk->enable_write_cache the true source for the information whether a writethrough mode must be implemented. The corresponding BDRV_O_CACHE_WB is only useless baggage we're carrying around, so now's the time to remove it. At the same time, we remove the 'cache.writeback' option parsing on the BDS level as the only effect was setting the BDRV_O_CACHE_WB flag. This change requires test cases that explicitly enabled the option to drop it. Other than that and the change of the error message when writethrough is enabled on the BDS level (from "Can't set writethrough mode" to "doesn't support the option"), there should be no change in behaviour. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-18 17:46:45 +01:00
QEMU_PROG: -drive if=none,file=TEST_DIR/t.qcow2,backing.file.filename=TEST_DIR/t.qcow2.base,node-name=image,backing.node-name=backing,backing.file.node-name=backing-file,file.node-name=file,file.cache.writeback=off: Block protocol 'file' doesn't support the option 'cache.writeback'
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
cache.writeback=off on backing
block: Remove BDRV_O_CACHE_WB The previous patches have successively made blk->enable_write_cache the true source for the information whether a writethrough mode must be implemented. The corresponding BDRV_O_CACHE_WB is only useless baggage we're carrying around, so now's the time to remove it. At the same time, we remove the 'cache.writeback' option parsing on the BDS level as the only effect was setting the BDRV_O_CACHE_WB flag. This change requires test cases that explicitly enabled the option to drop it. Other than that and the change of the error message when writethrough is enabled on the BDS level (from "Can't set writethrough mode" to "doesn't support the option"), there should be no change in behaviour. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-18 17:46:45 +01:00
QEMU_PROG: -drive if=none,file=TEST_DIR/t.qcow2,backing.file.filename=TEST_DIR/t.qcow2.base,node-name=image,backing.node-name=backing,backing.file.node-name=backing-file,file.node-name=file,backing.cache.writeback=off: Could not open backing file: Block format 'qcow2' does not support the option 'cache.writeback'
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
cache.writeback=off on backing-file
block: Remove BDRV_O_CACHE_WB The previous patches have successively made blk->enable_write_cache the true source for the information whether a writethrough mode must be implemented. The corresponding BDRV_O_CACHE_WB is only useless baggage we're carrying around, so now's the time to remove it. At the same time, we remove the 'cache.writeback' option parsing on the BDS level as the only effect was setting the BDRV_O_CACHE_WB flag. This change requires test cases that explicitly enabled the option to drop it. Other than that and the change of the error message when writethrough is enabled on the BDS level (from "Can't set writethrough mode" to "doesn't support the option"), there should be no change in behaviour. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-18 17:46:45 +01:00
QEMU_PROG: -drive if=none,file=TEST_DIR/t.qcow2,backing.file.filename=TEST_DIR/t.qcow2.base,node-name=image,backing.node-name=backing,backing.file.node-name=backing-file,file.node-name=file,backing.file.cache.writeback=off: Could not open backing file: Block protocol 'file' doesn't support the option 'cache.writeback'
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
cache.no-flush=on on none0
Cache mode: writeback, direct
Cache mode: writeback, direct
Cache mode: writeback, direct
Cache mode: writeback, direct
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback, direct
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
cache.no-flush=on on file
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback, direct
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Cache mode: writeback, direct
Cache mode: writeback, direct, ignore flushes
Cache mode: writeback, direct
Cache mode: writeback, direct
cache.no-flush=on on backing
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback, direct
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Cache mode: writeback, direct
Cache mode: writeback, direct
Cache mode: writeback, direct, ignore flushes
Cache mode: writeback, direct, ignore flushes
cache.no-flush=on on backing-file
Cache mode: writeback, direct
Cache mode: writeback, direct
Cache mode: writeback, direct
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback, direct
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Cache mode: writeback, direct, ignore flushes
--- Change cache modes with reopen (qemu-io command, options) ---
cache.direct=on on none0
Cache mode: writeback, direct
Cache mode: writeback, direct
Cache mode: writeback, direct
Cache mode: writeback, direct
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback, direct
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
cache.direct=on on file
Cache mode: writeback, direct
Cache mode: writeback, direct
Cache mode: writeback, direct
Cache mode: writeback, direct
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback, direct
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
cache.direct=on on backing
Cache mode: writeback, direct
Cache mode: writeback, direct
Cache mode: writeback, direct
Cache mode: writeback, direct
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback, direct
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
cache.direct=on on backing-file
Cache mode: writeback, direct
Cache mode: writeback, direct
Cache mode: writeback, direct
Cache mode: writeback, direct
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback, direct
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
cache.writeback=off on none0
Cache mode: writethrough, direct
Cache mode: writeback, direct
block: Make backing files always writeback First of all, we're generally not writing to backing files, but when we do, it's in the context of block jobs which know very well when to flush the image. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2016-03-04 14:52:32 +01:00
Cache mode: writeback, direct
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Cache mode: writeback, direct
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback, direct
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
cache.writeback=off on file
block: Remove BDRV_O_CACHE_WB The previous patches have successively made blk->enable_write_cache the true source for the information whether a writethrough mode must be implemented. The corresponding BDRV_O_CACHE_WB is only useless baggage we're carrying around, so now's the time to remove it. At the same time, we remove the 'cache.writeback' option parsing on the BDS level as the only effect was setting the BDRV_O_CACHE_WB flag. This change requires test cases that explicitly enabled the option to drop it. Other than that and the change of the error message when writethrough is enabled on the BDS level (from "Can't set writethrough mode" to "doesn't support the option"), there should be no change in behaviour. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-18 17:46:45 +01:00
QEMU_PROG: -drive if=none,file=TEST_DIR/t.qcow2,backing.file.filename=TEST_DIR/t.qcow2.base,node-name=image,backing.node-name=backing,backing.file.node-name=backing-file,file.node-name=file,file.cache.writeback=off: Block protocol 'file' doesn't support the option 'cache.writeback'
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
cache.writeback=off on backing
block: Remove BDRV_O_CACHE_WB The previous patches have successively made blk->enable_write_cache the true source for the information whether a writethrough mode must be implemented. The corresponding BDRV_O_CACHE_WB is only useless baggage we're carrying around, so now's the time to remove it. At the same time, we remove the 'cache.writeback' option parsing on the BDS level as the only effect was setting the BDRV_O_CACHE_WB flag. This change requires test cases that explicitly enabled the option to drop it. Other than that and the change of the error message when writethrough is enabled on the BDS level (from "Can't set writethrough mode" to "doesn't support the option"), there should be no change in behaviour. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-18 17:46:45 +01:00
QEMU_PROG: -drive if=none,file=TEST_DIR/t.qcow2,backing.file.filename=TEST_DIR/t.qcow2.base,node-name=image,backing.node-name=backing,backing.file.node-name=backing-file,file.node-name=file,backing.cache.writeback=off: Could not open backing file: Block format 'qcow2' does not support the option 'cache.writeback'
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
cache.writeback=off on backing-file
block: Remove BDRV_O_CACHE_WB The previous patches have successively made blk->enable_write_cache the true source for the information whether a writethrough mode must be implemented. The corresponding BDRV_O_CACHE_WB is only useless baggage we're carrying around, so now's the time to remove it. At the same time, we remove the 'cache.writeback' option parsing on the BDS level as the only effect was setting the BDRV_O_CACHE_WB flag. This change requires test cases that explicitly enabled the option to drop it. Other than that and the change of the error message when writethrough is enabled on the BDS level (from "Can't set writethrough mode" to "doesn't support the option"), there should be no change in behaviour. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-18 17:46:45 +01:00
QEMU_PROG: -drive if=none,file=TEST_DIR/t.qcow2,backing.file.filename=TEST_DIR/t.qcow2.base,node-name=image,backing.node-name=backing,backing.file.node-name=backing-file,file.node-name=file,backing.file.cache.writeback=off: Could not open backing file: Block protocol 'file' doesn't support the option 'cache.writeback'
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
cache.no-flush=on on none0
Cache mode: writeback, direct, ignore flushes
Cache mode: writeback, direct, ignore flushes
Cache mode: writeback, direct, ignore flushes
Cache mode: writeback, direct, ignore flushes
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback, direct, ignore flushes
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
cache.no-flush=on on file
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback, direct
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Cache mode: writeback, direct
Cache mode: writeback, direct, ignore flushes
Cache mode: writeback, direct
Cache mode: writeback, direct
cache.no-flush=on on backing
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback, direct
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Cache mode: writeback, direct
Cache mode: writeback, direct
Cache mode: writeback, direct, ignore flushes
Cache mode: writeback, direct, ignore flushes
cache.no-flush=on on backing-file
Cache mode: writeback, direct
Cache mode: writeback, direct
Cache mode: writeback, direct
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback, direct
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Cache mode: writeback, direct, ignore flushes
--- Change cache modes after snapshot ---
cache.direct=on on none0
Cache mode: writeback, direct
Cache mode: writeback, direct
Cache mode: writeback, direct
Cache mode: writeback, direct
Cache mode: writeback, direct
cache.direct=on on file
Cache mode: writeback, direct
Cache mode: writeback
Cache mode: writeback, direct
Cache mode: writeback
Cache mode: writeback
cache.direct=on on backing
Cache mode: writeback, direct
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback, direct
Cache mode: writeback, direct
cache.direct=on on backing-file
Cache mode: writeback, direct
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback, direct
cache.writeback=off on none0
Cache mode: writeback, direct
block: Move enable_write_cache to BB level Whether a write cache is used or not is a decision that concerns the user (e.g. the guest device) rather than the backend. It was already logically part of the BB level as bdrv_move_feature_fields() always kept it on top of the BDS tree; with this patch, the core of it (the actual flag and the additional flushes) is also implemented there. Direct callers of bdrv_open() must pass BDRV_O_CACHE_WB now if bs doesn't have a BlockBackend attached. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-04 14:28:01 +01:00
Cache mode: writeback
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Cache mode: writeback
block: Make backing files always writeback First of all, we're generally not writing to backing files, but when we do, it's in the context of block jobs which know very well when to flush the image. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2016-03-04 14:52:32 +01:00
Cache mode: writeback
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Cache mode: writeback
cache.writeback=off on file
block: Remove BDRV_O_CACHE_WB The previous patches have successively made blk->enable_write_cache the true source for the information whether a writethrough mode must be implemented. The corresponding BDRV_O_CACHE_WB is only useless baggage we're carrying around, so now's the time to remove it. At the same time, we remove the 'cache.writeback' option parsing on the BDS level as the only effect was setting the BDRV_O_CACHE_WB flag. This change requires test cases that explicitly enabled the option to drop it. Other than that and the change of the error message when writethrough is enabled on the BDS level (from "Can't set writethrough mode" to "doesn't support the option"), there should be no change in behaviour. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-18 17:46:45 +01:00
QEMU_PROG: -drive if=none,file=TEST_DIR/t.qcow2,backing.file.filename=TEST_DIR/t.qcow2.base,node-name=image,backing.node-name=backing,backing.file.node-name=backing-file,file.node-name=file,file.cache.writeback=off: Block protocol 'file' doesn't support the option 'cache.writeback'
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
cache.writeback=off on backing
block: Remove BDRV_O_CACHE_WB The previous patches have successively made blk->enable_write_cache the true source for the information whether a writethrough mode must be implemented. The corresponding BDRV_O_CACHE_WB is only useless baggage we're carrying around, so now's the time to remove it. At the same time, we remove the 'cache.writeback' option parsing on the BDS level as the only effect was setting the BDRV_O_CACHE_WB flag. This change requires test cases that explicitly enabled the option to drop it. Other than that and the change of the error message when writethrough is enabled on the BDS level (from "Can't set writethrough mode" to "doesn't support the option"), there should be no change in behaviour. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-18 17:46:45 +01:00
QEMU_PROG: -drive if=none,file=TEST_DIR/t.qcow2,backing.file.filename=TEST_DIR/t.qcow2.base,node-name=image,backing.node-name=backing,backing.file.node-name=backing-file,file.node-name=file,backing.cache.writeback=off: Could not open backing file: Block format 'qcow2' does not support the option 'cache.writeback'
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
cache.writeback=off on backing-file
block: Remove BDRV_O_CACHE_WB The previous patches have successively made blk->enable_write_cache the true source for the information whether a writethrough mode must be implemented. The corresponding BDRV_O_CACHE_WB is only useless baggage we're carrying around, so now's the time to remove it. At the same time, we remove the 'cache.writeback' option parsing on the BDS level as the only effect was setting the BDRV_O_CACHE_WB flag. This change requires test cases that explicitly enabled the option to drop it. Other than that and the change of the error message when writethrough is enabled on the BDS level (from "Can't set writethrough mode" to "doesn't support the option"), there should be no change in behaviour. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-18 17:46:45 +01:00
QEMU_PROG: -drive if=none,file=TEST_DIR/t.qcow2,backing.file.filename=TEST_DIR/t.qcow2.base,node-name=image,backing.node-name=backing,backing.file.node-name=backing-file,file.node-name=file,backing.file.cache.writeback=off: Could not open backing file: Block protocol 'file' doesn't support the option 'cache.writeback'
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
cache.no-flush=on on none0
Cache mode: writeback, direct
Cache mode: writeback, ignore flushes
Cache mode: writeback, ignore flushes
Cache mode: writeback, ignore flushes
Cache mode: writeback, ignore flushes
cache.no-flush=on on file
Cache mode: writeback, direct
Cache mode: writeback
Cache mode: writeback, ignore flushes
Cache mode: writeback
Cache mode: writeback
cache.no-flush=on on backing
Cache mode: writeback, direct
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback, ignore flushes
Cache mode: writeback, ignore flushes
cache.no-flush=on on backing-file
Cache mode: writeback, direct
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback, ignore flushes
--- Change cache mode in parent, child has explicit option in JSON ---
qemu-io: Use bdrv_parse_cache_mode() in reopen_f() We must forbid changing the WCE flag in bdrv_reopen() in the same patch, as otherwise the behaviour would change so that the flag takes precedence over the explicitly specified option. The correct value of the WCE flag depends on the BlockBackend user (e.g. guest device) and isn't a decision that the QMP client makes, so this change is what we want. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-18 15:36:31 +01:00
Cache mode: writeback, direct, ignore flushes
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Cache mode: writeback, direct, ignore flushes
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback, direct, ignore flushes
block: Reject writethrough mode except at the root Writethrough mode is going to become a BlockBackend feature rather than a BDS one, so forbid it in places where we won't be able to support it when the code finally matches the envisioned design. We only allowed setting the cache mode of non-root nodes after the 2.5 release, so we're still free to make this change. The target of block jobs is now always opened in a writeback mode because it doesn't have a BlockBackend attached. This makes more sense anyway because block jobs know when to flush. If the graph is modified on job completion, the original cache mode moves to the new root, so for the guest device writethough always stays enabled if it was configured this way. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2016-03-14 15:46:03 +01:00
Cache mode: writeback, ignore flushes
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
=== Check that referenced BDSes don't inherit ===
--- Configure cache modes on the command line ---
cache.direct=on on blk
Cache mode: writeback, direct
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback
cache.direct=on on file
Cache mode: writeback
Cache mode: writeback, direct
Cache mode: writeback
Cache mode: writeback
cache.direct=on on backing
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback, direct
Cache mode: writeback
cache.direct=on on backing-file
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback, direct
cache.writeback=off on blk
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback
cache.writeback=off on file
Cache mode: writeback
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Cache mode: writeback
Cache mode: writeback
cache.writeback=off on backing
Cache mode: writeback
Cache mode: writeback
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Cache mode: writeback
cache.writeback=off on backing-file
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
cache.no-flush=on on blk
Cache mode: writeback, ignore flushes
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback
cache.no-flush=on on file
Cache mode: writeback
Cache mode: writeback, ignore flushes
Cache mode: writeback
Cache mode: writeback
cache.no-flush=on on backing
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback, ignore flushes
Cache mode: writeback
cache.no-flush=on on backing-file
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback, ignore flushes
--- Cache modes after reopen (live snapshot) ---
cache.direct=on on blk
Cache mode: writeback, direct
Cache mode: writeback, direct
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback
cache.direct=on on file
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback, direct
Cache mode: writeback
Cache mode: writeback
cache.direct=on on backing
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback, direct
Cache mode: writeback
cache.direct=on on backing-file
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback, direct
cache.writeback=off on blk
Cache mode: writethrough
block: Move enable_write_cache to BB level Whether a write cache is used or not is a decision that concerns the user (e.g. the guest device) rather than the backend. It was already logically part of the BB level as bdrv_move_feature_fields() always kept it on top of the BDS tree; with this patch, the core of it (the actual flag and the additional flushes) is also implemented there. Direct callers of bdrv_open() must pass BDRV_O_CACHE_WB now if bs doesn't have a BlockBackend attached. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-04 14:28:01 +01:00
Cache mode: writeback
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback
cache.writeback=off on file
Cache mode: writeback
Cache mode: writeback
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Cache mode: writeback
Cache mode: writeback
cache.writeback=off on backing
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Cache mode: writeback
cache.writeback=off on backing-file
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
cache.no-flush=on on blk
Cache mode: writeback, ignore flushes
Cache mode: writeback, ignore flushes
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback
cache.no-flush=on on file
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback, ignore flushes
Cache mode: writeback
Cache mode: writeback
cache.no-flush=on on backing
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback, ignore flushes
Cache mode: writeback
cache.no-flush=on on backing-file
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback, ignore flushes
--- Change cache modes with reopen (qemu-io command, flags) ---
cache.direct=on on blk
Cache mode: writeback, direct
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback
cache.direct=on on file
Cache mode: writeback, direct
Cache mode: writeback, direct
Cache mode: writeback
Cache mode: writeback
cache.direct=on on backing
Cache mode: writeback, direct
Cache mode: writeback
Cache mode: writeback, direct
Cache mode: writeback
cache.direct=on on backing-file
Cache mode: writeback, direct
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback, direct
cache.writeback=off on blk
Cache mode: writeback, direct
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback
cache.writeback=off on file
Cache mode: writeback, direct
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Cache mode: writeback
Cache mode: writeback
cache.writeback=off on backing
Cache mode: writeback, direct
Cache mode: writeback
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Cache mode: writeback
cache.writeback=off on backing-file
Cache mode: writeback, direct
Cache mode: writeback
Cache mode: writeback
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
cache.no-flush=on on blk
Cache mode: writeback, direct
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback
cache.no-flush=on on file
Cache mode: writeback, direct
Cache mode: writeback, ignore flushes
Cache mode: writeback
Cache mode: writeback
cache.no-flush=on on backing
Cache mode: writeback, direct
Cache mode: writeback
Cache mode: writeback, ignore flushes
Cache mode: writeback
cache.no-flush=on on backing-file
Cache mode: writeback, direct
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback, ignore flushes
=== Reopening children instead of the root ===
--- Basic reopen ---
cache.direct=on on none0
Cache mode: writeback, direct
Cache mode: writeback, direct
Cache mode: writeback, direct
Cache mode: writeback, direct
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback, direct
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
cache.direct=on on file
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Cache mode: writeback
Cache mode: writeback, direct
Cache mode: writeback, direct
Cache mode: writeback, direct
cache.direct=on on backing
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback, direct
Cache mode: writeback, direct
cache.direct=on on backing-file
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback, direct
Cache mode: writeback, direct
cache.writeback=off on none0
Cache mode: writethrough
Cache mode: writeback
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback
block: Make backing files always writeback First of all, we're generally not writing to backing files, but when we do, it's in the context of block jobs which know very well when to flush the image. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2016-03-04 14:52:32 +01:00
Cache mode: writeback, direct
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Cache mode: writeback, direct
cache.writeback=off on file
block: Remove BDRV_O_CACHE_WB The previous patches have successively made blk->enable_write_cache the true source for the information whether a writethrough mode must be implemented. The corresponding BDRV_O_CACHE_WB is only useless baggage we're carrying around, so now's the time to remove it. At the same time, we remove the 'cache.writeback' option parsing on the BDS level as the only effect was setting the BDRV_O_CACHE_WB flag. This change requires test cases that explicitly enabled the option to drop it. Other than that and the change of the error message when writethrough is enabled on the BDS level (from "Can't set writethrough mode" to "doesn't support the option"), there should be no change in behaviour. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-18 17:46:45 +01:00
QEMU_PROG: -drive if=none,file=TEST_DIR/t.qcow2,backing.file.filename=TEST_DIR/t.qcow2.base,node-name=image,backing.node-name=backing,backing.file.node-name=backing-file,file.node-name=file,file.cache.writeback=off: Block protocol 'file' doesn't support the option 'cache.writeback'
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
cache.writeback=off on backing
block: Remove BDRV_O_CACHE_WB The previous patches have successively made blk->enable_write_cache the true source for the information whether a writethrough mode must be implemented. The corresponding BDRV_O_CACHE_WB is only useless baggage we're carrying around, so now's the time to remove it. At the same time, we remove the 'cache.writeback' option parsing on the BDS level as the only effect was setting the BDRV_O_CACHE_WB flag. This change requires test cases that explicitly enabled the option to drop it. Other than that and the change of the error message when writethrough is enabled on the BDS level (from "Can't set writethrough mode" to "doesn't support the option"), there should be no change in behaviour. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-18 17:46:45 +01:00
QEMU_PROG: -drive if=none,file=TEST_DIR/t.qcow2,backing.file.filename=TEST_DIR/t.qcow2.base,node-name=image,backing.node-name=backing,backing.file.node-name=backing-file,file.node-name=file,backing.cache.writeback=off: Could not open backing file: Block format 'qcow2' does not support the option 'cache.writeback'
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
cache.writeback=off on backing-file
block: Remove BDRV_O_CACHE_WB The previous patches have successively made blk->enable_write_cache the true source for the information whether a writethrough mode must be implemented. The corresponding BDRV_O_CACHE_WB is only useless baggage we're carrying around, so now's the time to remove it. At the same time, we remove the 'cache.writeback' option parsing on the BDS level as the only effect was setting the BDRV_O_CACHE_WB flag. This change requires test cases that explicitly enabled the option to drop it. Other than that and the change of the error message when writethrough is enabled on the BDS level (from "Can't set writethrough mode" to "doesn't support the option"), there should be no change in behaviour. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-18 17:46:45 +01:00
QEMU_PROG: -drive if=none,file=TEST_DIR/t.qcow2,backing.file.filename=TEST_DIR/t.qcow2.base,node-name=image,backing.node-name=backing,backing.file.node-name=backing-file,file.node-name=file,backing.file.cache.writeback=off: Could not open backing file: Block protocol 'file' doesn't support the option 'cache.writeback'
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
cache.no-flush=on on none0
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback, ignore flushes
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Cache mode: writeback, ignore flushes
Cache mode: writeback, ignore flushes
Cache mode: writeback, direct, ignore flushes
Cache mode: writeback, direct, ignore flushes
cache.no-flush=on on file
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Cache mode: writeback
Cache mode: writeback, ignore flushes
Cache mode: writeback, direct
Cache mode: writeback, direct
cache.no-flush=on on backing
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback, direct, ignore flushes
Cache mode: writeback, direct, ignore flushes
cache.no-flush=on on backing-file
block/qapi: Use blk_enable_write_cache() Now that WCE is handled on the BlockBackend level, the flag is meaningless for BDSes. As the schema requires us to fill the field, we return an enabled write cache for them. Note that this means that querying the BlockBackend name may return writethrough as the cache information, whereas querying the node-name of the root of that same BlockBackend will return writeback. This may appear odd at first, but it actually makes sense because it correctly repesents the layer that implements the WCE handling. This becomes more apparent when you consider nodes that are the root node of multiple BlockBackends, where each BB can have its own WCE setting. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-03 11:37:48 +01:00
Cache mode: writeback
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Cache mode: writeback
Cache mode: writeback
Cache mode: writeback, direct
Cache mode: writeback, direct, ignore flushes
--- Change cache mode after reopening child ---
Cache mode: writeback, direct
block: Move enable_write_cache to BB level Whether a write cache is used or not is a decision that concerns the user (e.g. the guest device) rather than the backend. It was already logically part of the BB level as bdrv_move_feature_fields() always kept it on top of the BDS tree; with this patch, the core of it (the actual flag and the additional flushes) is also implemented there. Direct callers of bdrv_open() must pass BDRV_O_CACHE_WB now if bs doesn't have a BlockBackend attached. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2016-03-04 14:28:01 +01:00
Cache mode: writeback
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
Cache mode: writeback, direct
Cache mode: writeback, ignore flushes
file-posix: Fix alignment after reopen changing O_DIRECT At the end of a reopen, we already call bdrv_refresh_limits(), which should update bs->request_alignment according to the new file descriptor. However, raw_probe_alignment() relies on s->needs_alignment and just uses 1 if it isn't set. We neglected to update this field, so starting with cache=writeback and then reopening with cache=none means that we get an incorrect bs->request_alignment == 1 and unaligned requests fail instead of being automatically aligned. Fix this by recalculating s->needs_alignment in raw_refresh_limits() before calling raw_probe_alignment(). Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20211104113109.56336-1-kwolf@redhat.com> Reviewed-by: Hanna Reitz <hreitz@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20211115145409.176785-13-kwolf@redhat.com> [hreitz: Fix iotest 142 for block sizes greater than 512 by operating on a file with a size of 1 MB] Signed-off-by: Hanna Reitz <hreitz@redhat.com> Message-Id: <20211116101431.105252-1-hreitz@redhat.com>
2021-11-16 11:14:31 +01:00
--- Alignment after changing O_DIRECT ---
Formatting 'TEST_DIR/t.IMGFMT', fmt=file size=1048576
wrote 4096/4096 bytes at offset 0
4 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
read 42/42 bytes at offset 42
42 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
read 42/42 bytes at offset 42
42 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
read 42/42 bytes at offset 42
42 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
read 42/42 bytes at offset 42
42 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
read 42/42 bytes at offset 42
42 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
read 42/42 bytes at offset 42
42 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
qemu-iotests: Test cache mode option inheritance 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 <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2015-05-08 18:06:47 +02:00
*** done