22.07.2021 15:26, Max Reitz wrote:
We largely have two cancel modes for jobs:
First, there is actual cancelling. The job is terminated as soon as
possible, without trying to reach a consistent result.
Second, we have mirror in the READY state. Technically, the job is not
really cancelled,
22.07.2021 15:26, Max Reitz wrote:
Most callers of job_is_cancelled() actually want to know whether the job
is on its way to immediate termination. For example, we refuse to pause
jobs that are cancelled; but this only makes sense for jobs that are
really actually cancelled.
A mirror job that
22.07.2021 15:26, Max Reitz wrote:
Callers should be able to specify whether they want job_cancel_sync() to
force-cancel the job or not.
In fact, almost all invocations do not care about consistency of the
result and just want the job to terminate as soon as possible, so they
should pass
On Thu, Jul 22, 2021 at 05:32:40PM +0100, Richard W.M. Jones wrote:
> Under SELinux, Unix domain sockets have two labels. One is on the
> disk and can be set with commands such as chcon(1). There is a
> different label stored in memory (called the process label). This can
> only be set by the
Under SELinux, Unix domain sockets have two labels. One is on the
disk and can be set with commands such as chcon(1). There is a
different label stored in memory (called the process label). This can
only be set by the process creating the socket. When using SELinux +
SVirt and wanting qemu to
https://bugzilla.redhat.com/show_bug.cgi?id=1984938
The purpose of the patch is explained in the commit message / bug. In
the cover I want to explain a couple of design choices.
If libselinux isn't available at build time then the --selinux-label
option is still present. It does not appear in
22.07.2021 15:26, Max Reitz wrote:
An error does not take us out of the READY phase, which is what
s->synced signifies. It does of course mean that source and target are
no longer in sync, but that is what s->actively_sync is for -- s->synced
never meant that source and target are in sync, only
Test what happens when there is an I/O error after a mirror job in the
READY phase has been cancelled.
Signed-off-by: Max Reitz
---
.../tests/mirror-ready-cancel-error | 143 ++
.../tests/mirror-ready-cancel-error.out | 5 +
2 files changed, 148 insertions(+)
We must check whether the job is force-cancelled early in our main loop,
most importantly before any `continue` statement. For example, we used
to have `continue`s before our current checking location that are
triggered by `mirror_flush()` failing. So, if `mirror_flush()` kept
failing,
We largely have two cancel modes for jobs:
First, there is actual cancelling. The job is terminated as soon as
possible, without trying to reach a consistent result.
Second, we have mirror in the READY state. Technically, the job is not
really cancelled, but it just is a different completion
Callers should be able to specify whether they want job_cancel_sync() to
force-cancel the job or not.
In fact, almost all invocations do not care about consistency of the
result and just want the job to terminate as soon as possible, so they
should pass force=true. The replication block driver
An error does not take us out of the READY phase, which is what
s->synced signifies. It does of course mean that source and target are
no longer in sync, but that is what s->actively_sync is for -- s->synced
never meant that source and target are in sync, only that they were at
some point (and at
Most callers of job_is_cancelled() actually want to know whether the job
is on its way to immediate termination. For example, we refuse to pause
jobs that are cancelled; but this only makes sense for jobs that are
really actually cancelled.
A mirror job that is cancelled during READY with
Hi,
This is a rather complex series with changes that aren’t exactly local
to the mirror job, so maybe it’s too complex for 6.1.
However, it is a bug fix, and not an insignificant one, though probably
not a regression of any kind.
Bug report:
https://gitlab.com/qemu-project/qemu/-/issues/462
21.07.2021 23:46, Eric Blake wrote:
Add a regression test to make sure we detect attempts to use 'qemu-img
bitmap' to modify an in-use local file.
Suggested-by: Nir Soffer
Signed-off-by: Eric Blake
---
Sadly, this missed my bitmaps pull request today. If there's any
reason to respin that
This simple patch suppresses a warning message from qemu-nbd when a
client abruptly disconnects. There is a way to work around this in
the client (by shutting down the connection properly). Nevertheless
the "Broken pipe" error seems unnecessary to me as it does not convey
any useful information
$ rm -f /tmp/sock /tmp/pid
$ qemu-img create -f qcow2 /tmp/disk.qcow2 1M
$ qemu-nbd -t --format=qcow2 --socket=/tmp/sock --pid-file=/tmp/pid
/tmp/disk.qcow2 &
$ nbdsh -u 'nbd+unix:///?socket=/tmp/sock' -c 'h.get_size()'
qemu-nbd: Disconnect client, due to: Failed to send reply: Unable to write to
在 2021/7/21 下午4:59, Jonah Palmer 写道:
On 7/13/21 10:37 PM, Jason Wang wrote:
在 2021/7/12 下午6:35, Jonah Palmer 写道:
From: Laurent Vivier
This new command shows internal status of a VirtQueue.
(vrings and indexes).
Signed-off-by: Laurent Vivier
Signed-off-by: Jonah Palmer
---
在 2021/7/21 下午5:11, Jonah Palmer 写道:
On 7/13/21 10:40 PM, Jason Wang wrote:
在 2021/7/12 下午6:35, Jonah Palmer 写道:
+void hmp_virtio_queue_status(Monitor *mon, const QDict *qdict)
+{
+ Error *err = NULL;
+ const char *path = qdict_get_try_str(qdict, "path");
+ int queue =
在 2021/7/21 下午4:53, Jonah Palmer 写道:
Hi Jason. My apologies for the delayed response, several work-related
things came up recently, but they're slowing down now so I'm turning
my attention these patches to get taken care of.
A few questions and comments below (and in other following
20 matches
Mail list logo
