Move bootindex.txt into the system section of the manual and turn it
into rST format. To make the document make more sense in the context
of the system manual, expand the title and introductory paragraphs to
give more context.
Signed-off-by: Peter Maydell
---
docs/bootindex.txt| 52
27.07.2021 19:47, Vladimir Sementsov-Ogievskiy wrote:
Hi all!
That's an alternative to (part of) Max's
"[PATCH for-6.1? v2 0/7] mirror: Handle errors after READY cancel"
and shows' my idea of handling soft-cancelling READY mirror case
directly in qmp_block_job_cancel. And cleanup all other job
Now, when soft-cancelling READY mirror handled in
qmp_block_job_cancel(), no other functions need to care of it:
cancel is always force.
So drop unused code paths.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
include/qemu/job.h | 14 --
block/backup.c
Soft cancel of READY mirror is more like completion than cancelling. We
have bugs and misunderstanding because of this feature. Now, let's
handle it the other way to drop force cancelling at all in the
following commit.
This makes internal implementation cleaner. Still, we should deprecate
and
It's an alternative for soft-cancelling mirror job after READY: mirror
should finish all in-flight requests, but don't change block graph in
any way.
To be used in the next commit.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
include/qemu/job.h | 5 -
block/mirror.c
Hi all!
That's an alternative to (part of) Max's
"[PATCH for-6.1? v2 0/7] mirror: Handle errors after READY cancel"
and shows' my idea of handling soft-cancelling READY mirror case
directly in qmp_block_job_cancel. And cleanup all other job cancelling
functions.
That's untested draft, don't take
On Tue, Jul 27, 2021 at 1:26 PM Thomas Huth wrote:
>
> The iotests 197 and 215 are occasionally failing in the gitlab-CI now.
> According to the log, the failure is "./common.rc: Killed" which might
> be an indication that the process has been killed due to out-of-memory
> reasons. Both tests are
On 7/27/21 6:25 PM, Thomas Huth wrote:
> The iotests 197 and 215 are occasionally failing in the gitlab-CI now.
> According to the log, the failure is "./common.rc: Killed" which might
> be an indication that the process has been killed due to out-of-memory
> reasons. Both tests are doing a big
On Tue, Jul 27, 2021 at 06:25:42PM +0200, Thomas Huth wrote:
> The iotests 197 and 215 are occasionally failing in the gitlab-CI now.
> According to the log, the failure is "./common.rc: Killed" which might
> be an indication that the process has been killed due to out-of-memory
> reasons. Both
The iotests 197 and 215 are occasionally failing in the gitlab-CI now.
According to the log, the failure is "./common.rc: Killed" which might
be an indication that the process has been killed due to out-of-memory
reasons. Both tests are doing a big read with 2G that likely causes
this issue. It
On 27.07.21 17:49, Kevin Wolf wrote:
When bdrv_pad_request() fails in bdrv_co_preadv_part(), bs->in_flight
has been increased, but is never decreased again. This leads to a hang
when trying to drain the block node.
This bug was observed with Windows guests which issue a request that
fully uses
When bdrv_pad_request() fails in bdrv_co_preadv_part(), bs->in_flight
has been increased, but is never decreased again. This leads to a hang
when trying to drain the block node.
This bug was observed with Windows guests which issue a request that
fully uses IOV_MAX during installation, so that
27.07.2021 18:39, Max Reitz wrote:
On 27.07.21 15:04, Vladimir Sementsov-Ogievskiy wrote:
26.07.2021 17:46, 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
On 27.07.21 15:13, Vladimir Sementsov-Ogievskiy wrote:
26.07.2021 17:46, Max Reitz wrote:
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
On 27.07.21 15:04, Vladimir Sementsov-Ogievskiy wrote:
26.07.2021 17:46, 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
On 27.07.21 16:47, Vladimir Sementsov-Ogievskiy wrote:
26.07.2021 10:09, Max Reitz wrote:
job->ret = -ECANCELED;
}
if (job->ret) {
@@ -704,7 +709,7 @@ static int job_finalize_single(Job *job)
/* Emit events only if we actually started */
if
26.07.2021 10:09, Max Reitz wrote:
job->ret = -ECANCELED;
}
if (job->ret) {
@@ -704,7 +709,7 @@ static int job_finalize_single(Job *job)
/* Emit events only if we actually started */
if (job_started(job)) {
- if (job_is_cancelled(job)) {
+ if
On Mon, 26 Jul 2021 at 20:19, Klaus Jensen wrote:
>
> From: Klaus Jensen
>
> Hi Peter,
>
> The following changes since commit 1d6f147f043bece029a795c6eb9d43c1abd909b6:
>
> Merge remote-tracking branch 'remotes/quic/tags/pull-hex-20210725' into
> staging (2021-07-26 13:36:51 +0100)
>
> are
On 21/07/2021 19.22, Daniel P. Berrangé wrote:
Peter caught the following transient fail on the staging tree:
https://gitlab.com/qemu-project/qemu/-/jobs/1438817749
--- /builds/qemu-project/qemu/tests/qemu-iotests/197.out
+++ 197.out.bad
@@ -12,13 +12,12 @@
128 KiB, X ops; XX:XX:XX.X (XXX
26.07.2021 17:46, Max Reitz wrote:
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
Reviewed-by: Vladimir Sementsov-Ogievskiy
Tested-by: Vladimir Sementsov-Ogievskiy
--
Best regards,
Vladimir
26.07.2021 17:46, Max Reitz wrote:
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
26.07.2021 17:46, 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
26.07.2021 17:46, 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,
26.07.2021 17:46, Max Reitz wrote:
As of HEAD^, there is no meaning to s->synced other than whether the job
is READY or not. job_is_ready() gives us that information, too.
Suggested-by: Vladimir Sementsov-Ogievskiy
Signed-off-by: Max Reitz
Reviewed-by: Vladimir Sementsov-Ogievskiy
--
Best
24 matches
Mail list logo
