On Thu 06 Sep 2018 11:37:08 AM CEST, Alberto Garcia wrote:
> 'discard' is one of the basic BlockdevOptions available for all
> drivers, but it's not handled by bdrv_reopen_prepare() so any attempt
> to change it results in an error:
>
>(qemu) qemu-io virtio0 "reopen -o discard=on"
>Cannot
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
include/block/block_backup.h | 13
block/backup.c | 38 +++-
2 files changed, 7 insertions(+), 44 deletions(-)
diff --git a/include/block/block_backup.h b/include/block/block_backup.h
index
Hi all!
We finally implemented fleecing scheme, create a test case for it (222)
and even made it safe (f8d59dfb40).
However, fleecing is used inside block-replication long ago, and to make
the scheme safe it uses direct interface to backup-job copy requests
synchronization, which can be dropped n
After commit f8d59dfb40
"block/backup: fix fleecing scheme: use serialized writes" fleecing
(specifically reading from backup target, when backup source is in
backing chain of backup target) is safe, because all backup-job writes
to target are serialized. Therefore we don't need additional
sync
This patch replaces the bdrv_reopen() calls that set and remove the
BDRV_O_RDWR flag with the new bdrv_reopen_set_read_only() function.
Signed-off-by: Alberto Garcia
---
block/commit.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/block/commit.c b/block/co
If qemu_opts_absorb_qdict() fails and we carry on and call
update_flags_from_options() then that can result on a failed
assertion:
$ qemu-io -c 'reopen -o read-only=foo' hd.qcow2
block.c:1101: update_flags_from_options: Assertion `qemu_opt_find(opts,
BDRV_OPT_CACHE_DIRECT)' failed.
Abort
This patch replaces the bdrv_reopen() calls that set and remove the
BDRV_O_RDWR flag with the new bdrv_reopen_set_read_only() function.
Signed-off-by: Alberto Garcia
---
block/stream.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/block/stream.c b/blo
This patch replaces the bdrv_reopen() calls that set and remove the
BDRV_O_RDWR flag with the new bdrv_reopen_set_read_only() function.
Signed-off-by: Alberto Garcia
---
blockdev.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/blockdev.c b/blockdev.c
index 58e057b0d9..2f2
Most callers of bdrv_reopen() only use it to switch a BlockDriverState
between read-only and read-write, so this patch adds a new function
that does just that.
We also want to get rid of the flags parameter in the bdrv_reopen()
API, so this function sets the "read-only" option and passes the
origi
This patch replaces the bdrv_reopen() calls that set and remove the
BDRV_O_RDWR flag with the new bdrv_reopen_set_read_only() function.
Signed-off-by: Alberto Garcia
---
block/commit.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/block/commit.c b/block/commit.c
inde
Now that all callers are passing all flag changes as QDict options,
the flags parameter is no longer necessary, so we can get rid of it.
Signed-off-by: Alberto Garcia
---
block.c | 5 +++--
block/replication.c | 6 ++
include/block/block.h | 3 +--
qemu-io-cmds.c| 2 +
No one is using this function anymore, so we can safely remove it
Signed-off-by: Alberto Garcia
---
block.c | 21 -
include/block/block.h | 1 -
2 files changed, 22 deletions(-)
diff --git a/block.c b/block.c
index ac945b4bc8..3751167434 100644
--- a/block.c
+
The 'block-commit' QMP command is implemented internally using two
different drivers. If the source image is the active layer then the
mirror driver is used (commit_active_start()), otherwise the commit
driver is used (commit_start()).
In both cases the destination image must be put temporarily in
Hi,
in the description of my "Misc reopen-related patches" I said that the
next series after that one would be the implementation of the
blockdev-reopen QMP command. That's not going to be the case after all
because I have a dozen of new patches that I wanted to publish now.
So here's what's goin
When reopen_f() puts a block device in the reopen queue, some of the
new options are passed using a QDict, but others ("read-only" and the
cache options) are passed as flags.
This patch puts those flags in the QDict. This way the flags parameter
becomes redundant and we'll be able to get rid of it
Now that all callers are passing the new options using the QDict we no
longer need the 'flags' parameter.
This patch makes the following changes:
1) The update_options_from_flags() call is no longer necessary
so it can be removed.
2) The update_flags_from_options() call is now used i
This patch replaces the bdrv_reopen() calls that set and remove the
BDRV_O_RDWR flag with the new bdrv_reopen_set_read_only() function.
Signed-off-by: Alberto Garcia
---
blockdev.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/blockdev.c b/blockdev.c
index 72f5347df
This patch replaces the bdrv_reopen() calls that set and remove the
BDRV_O_RDWR flag with the new bdrv_reopen_set_read_only() function.
Signed-off-by: Alberto Garcia
---
block.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/block.c b/block.c
index e023945c8e..ac9
This function is used to put the hidden and secondary disks in
read-write mode before launching the backup job, and back in read-only
mode afterwards.
This patch does the following changes:
- Use an options QDict with the "read-only" option instead of
passing the changes as flags only.
-
On Tue 11 Sep 2018 02:32:56 PM CEST, Alberto Garcia wrote:
> If qemu_opts_absorb_qdict() fails and we carry on and call
> update_flags_from_options() then that can result on a failed
> assertion:
>
>$ qemu-io -c 'reopen -o read-only=foo' hd.qcow2
>block.c:1101: update_flags_from_options: As
On 18/09/2018 16:56, Kevin Wolf wrote:
> Am 18.09.2018 um 16:12 hat Paolo Bonzini geschrieben:
>> On 18/09/2018 13:34, Kevin Wolf wrote:
But then basically the main issue is mirror.c's call to
bdrv_drained_begin/end. There are no other calls to
bdrv_drained_begin/end inside coroutin
We named these using underscores instead of the preferred dash,
document this nearby so we cannot possibly forget to rectify this
when we remove the 'x-' prefixes when the feature becomes stable.
We do not implement the change ahead of time to avoid more work
for libvirt to do in order to figure o
On 9/19/18 2:09 PM, John Snow wrote:
We named these using underscores instead of the preferred dash,
document this nearby so we cannot possibly forget to rectify this
when we remove the 'x-' prefixes when the feature becomes stable.
We do not implement the change ahead of time to avoid more work
We wish to prohibit merging to read-only bitmaps and frozen bitmaps,
but "disabled" bitmaps only preclude their recording of live, new
information. It does not prohibit them from manual writes at the behest
of the user, as is the case for merge operations.
Reported-by: Eric Blake
Signed-off-by: J
On 9/19/18 2:58 PM, John Snow wrote:
We wish to prohibit merging to read-only bitmaps and frozen bitmaps,
but "disabled" bitmaps only preclude their recording of live, new
information. It does not prohibit them from manual writes at the behest
of the user, as is the case for merge operations.
I
On 9/19/18 2:09 PM, John Snow wrote:
In the subject-line: s/birtmap/bitmap/
We named these using underscores instead of the preferred dash,
document this nearby so we cannot possibly forget to rectify this
when we remove the 'x-' prefixes when the feature becomes stable.
We do not implement th
On 9/19/18 2:58 PM, John Snow wrote:
We wish to prohibit merging to read-only bitmaps and frozen bitmaps,
but "disabled" bitmaps only preclude their recording of live, new
information. It does not prohibit them from manual writes at the behest
of the user, as is the case for merge operations.
Re
On 09/19/2018 05:08 PM, Eric Blake wrote:
> On 9/19/18 2:58 PM, John Snow wrote:
>> We wish to prohibit merging to read-only bitmaps and frozen bitmaps,
>> but "disabled" bitmaps only preclude their recording of live, new
>> information. It does not prohibit them from manual writes at the behest
On 09/19/2018 04:58 PM, Eric Blake wrote:
> On 9/19/18 2:58 PM, John Snow wrote:
>> We wish to prohibit merging to read-only bitmaps and frozen bitmaps,
>> but "disabled" bitmaps only preclude their recording of live, new
>> information. It does not prohibit them from manual writes at the behest
On 09/19/2018 04:58 PM, Eric Blake wrote:
> On 9/19/18 2:58 PM, John Snow wrote:
>> We wish to prohibit merging to read-only bitmaps and frozen bitmaps,
>> but "disabled" bitmaps only preclude their recording of live, new
>> information. It does not prohibit them from manual writes at the behest
30 matches
Mail list logo
