2012-09-28 17:22:47 +02:00
|
|
|
/*
|
|
|
|
* Declarations for long-running block device operations
|
|
|
|
*
|
|
|
|
* Copyright (c) 2011 IBM Corp.
|
|
|
|
* Copyright (c) 2012 Red Hat, Inc.
|
|
|
|
*
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
|
|
* of this software and associated documentation files (the "Software"), to deal
|
|
|
|
* in the Software without restriction, including without limitation the rights
|
|
|
|
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
|
|
* copies of the Software, and to permit persons to whom the Software is
|
|
|
|
* furnished to do so, subject to the following conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice shall be included in
|
|
|
|
* all copies or substantial portions of the Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
|
|
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
|
|
|
|
* THE SOFTWARE.
|
|
|
|
*/
|
2016-06-29 15:29:06 +02:00
|
|
|
|
2012-09-28 17:22:47 +02:00
|
|
|
#ifndef BLOCKJOB_H
|
2016-06-29 15:29:06 +02:00
|
|
|
#define BLOCKJOB_H
|
2012-09-28 17:22:47 +02:00
|
|
|
|
2012-12-17 18:19:44 +01:00
|
|
|
#include "block/block.h"
|
2018-01-18 20:20:24 +01:00
|
|
|
#include "qemu/ratelimit.h"
|
2012-09-28 17:22:47 +02:00
|
|
|
|
2018-01-18 20:25:40 +01:00
|
|
|
#define BLOCK_JOB_SLICE_TIME 100000000ULL /* ns */
|
|
|
|
|
2016-10-27 18:07:00 +02:00
|
|
|
typedef struct BlockJobDriver BlockJobDriver;
|
|
|
|
typedef struct BlockJobTxn BlockJobTxn;
|
2012-09-28 17:22:47 +02:00
|
|
|
|
|
|
|
/**
|
|
|
|
* BlockJob:
|
|
|
|
*
|
|
|
|
* Long-running operation on a BlockDriverState.
|
|
|
|
*/
|
2016-10-27 18:07:00 +02:00
|
|
|
typedef struct BlockJob {
|
2012-09-28 17:22:47 +02:00
|
|
|
/** The job type, including the job vtable. */
|
2013-10-08 11:29:38 +02:00
|
|
|
const BlockJobDriver *driver;
|
2012-09-28 17:22:47 +02:00
|
|
|
|
|
|
|
/** The block device on which the job is operating. */
|
2016-04-08 14:51:09 +02:00
|
|
|
BlockBackend *blk;
|
2012-09-28 17:22:47 +02:00
|
|
|
|
2015-09-16 13:34:54 +02:00
|
|
|
/**
|
2016-10-27 18:06:55 +02:00
|
|
|
* The ID of the block job. May be NULL for internal jobs.
|
2015-09-16 13:34:54 +02:00
|
|
|
*/
|
|
|
|
char *id;
|
|
|
|
|
2012-09-28 17:22:47 +02:00
|
|
|
/**
|
|
|
|
* The coroutine that executes the job. If not NULL, it is
|
|
|
|
* reentered when busy is false and the job is cancelled.
|
|
|
|
*/
|
|
|
|
Coroutine *co;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Set to true if the job should cancel itself. The flag must
|
|
|
|
* always be tested just before toggling the busy flag from false
|
|
|
|
* to true. After a job has been cancelled, it should only yield
|
2014-07-07 15:18:02 +02:00
|
|
|
* if #aio_poll will ("sooner or later") reenter the coroutine.
|
2012-09-28 17:22:47 +02:00
|
|
|
*/
|
|
|
|
bool cancelled;
|
|
|
|
|
block/mirror: change the semantic of 'force' of block-job-cancel
When doing drive mirror to a low speed shared storage, if there was heavy
BLK IO write workload in VM after the 'ready' event, drive mirror block job
can't be canceled immediately, it would keep running until the heavy BLK IO
workload stopped in the VM.
Libvirt depends on the current block-job-cancel semantics, which is that
when used without a flag after the 'ready' event, the command blocks
until data is in sync. However, these semantics are awkward in other
situations, for example, people may use drive mirror for realtime
backups while still wanting to use block live migration. Libvirt cannot
start a block live migration while another drive mirror is in progress,
but the user would rather abandon the backup attempt as broken and
proceed with the live migration than be stuck waiting for the current
drive mirror backup to finish.
The drive-mirror command already includes a 'force' flag, which libvirt
does not use, although it documented the flag as only being useful to
quit a job which is paused. However, since quitting a paused job has
the same effect as abandoning a backup in a non-paused job (namely, the
destination file is not in sync, and the command completes immediately),
we can just improve the documentation to make the force flag obviously
useful.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Jeff Cody <jcody@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>
Cc: Max Reitz <mreitz@redhat.com>
Cc: Eric Blake <eblake@redhat.com>
Cc: John Snow <jsnow@redhat.com>
Reported-by: Huaitong Han <huanhuaitong@didichuxing.com>
Signed-off-by: Huaitong Han <huanhuaitong@didichuxing.com>
Signed-off-by: Liang Li <liliangleo@didichuxing.com>
Signed-off-by: Jeff Cody <jcody@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-03-13 13:12:16 +01:00
|
|
|
/**
|
|
|
|
* Set to true if the job should abort immediately without waiting
|
|
|
|
* for data to be in sync.
|
|
|
|
*/
|
|
|
|
bool force;
|
|
|
|
|
2012-09-28 17:22:50 +02:00
|
|
|
/**
|
2015-04-03 16:05:18 +02:00
|
|
|
* Counter for pause request. If non-zero, the block job is either paused,
|
|
|
|
* or if busy == true will pause itself as soon as possible.
|
2012-09-28 17:22:50 +02:00
|
|
|
*/
|
2015-04-03 16:05:18 +02:00
|
|
|
int pause_count;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Set to true if the job is paused by user. Can be unpaused with the
|
|
|
|
* block-job-resume QMP command.
|
|
|
|
*/
|
|
|
|
bool user_paused;
|
2012-09-28 17:22:50 +02:00
|
|
|
|
2012-09-28 17:22:47 +02:00
|
|
|
/**
|
2016-06-16 18:56:24 +02:00
|
|
|
* Set to false by the job while the coroutine has yielded and may be
|
|
|
|
* re-entered by block_job_enter(). There may still be I/O or event loop
|
2017-11-29 11:25:13 +01:00
|
|
|
* activity pending. Accessed under block_job_mutex (in blockjob.c).
|
2012-09-28 17:22:47 +02:00
|
|
|
*/
|
|
|
|
bool busy;
|
|
|
|
|
2016-06-16 18:56:24 +02:00
|
|
|
/**
|
|
|
|
* Set to true by the job while it is in a quiescent state, where
|
|
|
|
* no I/O or event loop activity is pending.
|
|
|
|
*/
|
|
|
|
bool paused;
|
|
|
|
|
2014-10-24 15:57:34 +02:00
|
|
|
/**
|
|
|
|
* Set to true when the job is ready to be completed.
|
|
|
|
*/
|
|
|
|
bool ready;
|
|
|
|
|
2016-02-02 03:12:24 +01:00
|
|
|
/**
|
|
|
|
* Set to true when the job has deferred work to the main loop.
|
|
|
|
*/
|
|
|
|
bool deferred_to_main_loop;
|
|
|
|
|
2016-04-04 15:43:51 +02:00
|
|
|
/** Element of the list of block jobs */
|
|
|
|
QLIST_ENTRY(BlockJob) job_list;
|
|
|
|
|
block: introduce block job error
The following behaviors are possible:
'report': The behavior is the same as in 1.1. An I/O error,
respectively during a read or a write, will complete the job immediately
with an error code.
'ignore': An I/O error, respectively during a read or a write, will be
ignored. For streaming, the job will complete with an error and the
backing file will be left in place. For mirroring, the sector will be
marked again as dirty and re-examined later.
'stop': The job will be paused and the job iostatus will be set to
failed or nospace, while the VM will keep running. This can only be
specified if the block device has rerror=stop and werror=stop or enospc.
'enospc': Behaves as 'stop' for ENOSPC errors, 'report' for others.
In all cases, even for 'report', the I/O error is reported as a QMP
event BLOCK_JOB_ERROR, with the same arguments as BLOCK_IO_ERROR.
It is possible that while stopping the VM a BLOCK_IO_ERROR event will be
reported and will clobber the event from BLOCK_JOB_ERROR, or vice versa.
This is not really avoidable since stopping the VM completes all pending
I/O requests. In fact, it is already possible now that a series of
BLOCK_IO_ERROR events are reported with rerror=stop, because vm_stop
calls bdrv_drain_all and this can generate further errors.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2012-09-28 17:22:58 +02:00
|
|
|
/** Status that is published by the query-block-jobs QMP API */
|
|
|
|
BlockDeviceIoStatus iostatus;
|
|
|
|
|
2012-09-28 17:22:47 +02:00
|
|
|
/** Offset that is published by the query-block-jobs QMP API */
|
|
|
|
int64_t offset;
|
|
|
|
|
|
|
|
/** Length that is published by the query-block-jobs QMP API */
|
|
|
|
int64_t len;
|
|
|
|
|
|
|
|
/** Speed that was set with @block_job_set_speed. */
|
|
|
|
int64_t speed;
|
|
|
|
|
2018-01-18 20:20:24 +01:00
|
|
|
/** Rate limiting data structure for implementing @speed. */
|
|
|
|
RateLimit limit;
|
|
|
|
|
2012-09-28 17:22:47 +02:00
|
|
|
/** The completion function that will be called when the job completes. */
|
2014-10-07 13:59:15 +02:00
|
|
|
BlockCompletionFunc *cb;
|
2012-09-28 17:22:47 +02:00
|
|
|
|
2014-05-23 15:29:43 +02:00
|
|
|
/** Block other operations when block job is running */
|
|
|
|
Error *blocker;
|
|
|
|
|
2016-10-28 09:08:04 +02:00
|
|
|
/** BlockDriverStates that are involved in this block job */
|
|
|
|
GSList *nodes;
|
|
|
|
|
2012-09-28 17:22:47 +02:00
|
|
|
/** The opaque value that is passed to the completion function. */
|
|
|
|
void *opaque;
|
2015-11-06 00:13:11 +01:00
|
|
|
|
|
|
|
/** Reference count of the block job */
|
|
|
|
int refcnt;
|
2015-11-06 00:13:13 +01:00
|
|
|
|
2018-03-10 09:27:28 +01:00
|
|
|
/** True when job has reported completion by calling block_job_completed. */
|
2015-11-06 00:13:13 +01:00
|
|
|
bool completed;
|
|
|
|
|
2018-03-10 09:27:28 +01:00
|
|
|
/** ret code passed to block_job_completed. */
|
2015-11-06 00:13:13 +01:00
|
|
|
int ret;
|
|
|
|
|
2017-11-29 11:25:13 +01:00
|
|
|
/**
|
|
|
|
* Timer that is used by @block_job_sleep_ns. Accessed under
|
|
|
|
* block_job_mutex (in blockjob.c).
|
|
|
|
*/
|
|
|
|
QEMUTimer sleep_timer;
|
|
|
|
|
blockjobs: add status enum
We're about to add several new states, and booleans are becoming
unwieldly and difficult to reason about. It would help to have a
more explicit bookkeeping of the state of blockjobs. To this end,
add a new "status" field and add our existing states in a redundant
manner alongside the bools they are replacing:
UNDEFINED: Placeholder, default state. Not currently visible to QMP
unless changes occur in the future to allow creating jobs
without starting them via QMP.
CREATED: replaces !!job->co && paused && !busy
RUNNING: replaces effectively (!paused && busy)
PAUSED: Nearly redundant with info->paused, which shows pause_count.
This reports the actual status of the job, which almost always
matches the paused request status. It differs in that it is
strictly only true when the job has actually gone dormant.
READY: replaces job->ready.
STANDBY: Paused, but job->ready is true.
New state additions in coming commits will not be quite so redundant:
WAITING: Waiting on transaction. This job has finished all the work
it can until the transaction converges, fails, or is canceled.
PENDING: Pending authorization from user. This job has finished all the
work it can until the job or transaction is finalized via
block_job_finalize. This implies the transaction has converged
and left the WAITING phase.
ABORTING: Job has encountered an error condition and is in the process
of aborting.
CONCLUDED: Job has ceased all operations and has a return code available
for query and may be dismissed via block_job_dismiss.
NULL: Job has been dismissed and (should) be destroyed. Should never
be visible to QMP.
Some of these states appear somewhat superfluous, but it helps define the
expected flow of a job; so some of the states wind up being synchronous
empty transitions. Importantly, jobs can be in only one of these states
at any given time, which helps code and external users alike reason about
the current condition of a job unambiguously.
Signed-off-by: John Snow <jsnow@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-03-10 09:27:29 +01:00
|
|
|
/** Current state; See @BlockJobStatus for details. */
|
|
|
|
BlockJobStatus status;
|
|
|
|
|
2018-03-10 09:27:42 +01:00
|
|
|
/** True if this job should automatically finalize itself */
|
|
|
|
bool auto_finalize;
|
|
|
|
|
2018-03-10 09:27:36 +01:00
|
|
|
/** True if this job should automatically dismiss itself */
|
|
|
|
bool auto_dismiss;
|
|
|
|
|
2015-11-06 00:13:15 +01:00
|
|
|
BlockJobTxn *txn;
|
|
|
|
QLIST_ENTRY(BlockJob) txn_list;
|
2016-10-27 18:07:00 +02:00
|
|
|
} BlockJob;
|
2012-09-28 17:22:47 +02:00
|
|
|
|
2016-10-27 18:06:56 +02:00
|
|
|
typedef enum BlockJobCreateFlags {
|
2018-03-10 09:27:28 +01:00
|
|
|
/* Default behavior */
|
2016-10-27 18:06:56 +02:00
|
|
|
BLOCK_JOB_DEFAULT = 0x00,
|
2018-03-10 09:27:28 +01:00
|
|
|
/* BlockJob is not QMP-created and should not send QMP events */
|
2016-10-27 18:06:56 +02:00
|
|
|
BLOCK_JOB_INTERNAL = 0x01,
|
2018-03-10 09:27:42 +01:00
|
|
|
/* BlockJob requires manual finalize step */
|
|
|
|
BLOCK_JOB_MANUAL_FINALIZE = 0x02,
|
2018-03-10 09:27:36 +01:00
|
|
|
/* BlockJob requires manual dismiss step */
|
|
|
|
BLOCK_JOB_MANUAL_DISMISS = 0x04,
|
2016-10-27 18:06:56 +02:00
|
|
|
} BlockJobCreateFlags;
|
|
|
|
|
2016-04-04 15:43:51 +02:00
|
|
|
/**
|
|
|
|
* block_job_next:
|
|
|
|
* @job: A block job, or %NULL.
|
|
|
|
*
|
|
|
|
* Get the next element from the list of block jobs after @job, or the
|
|
|
|
* first one if @job is %NULL.
|
|
|
|
*
|
|
|
|
* Returns the requested job, or %NULL if there are no more jobs left.
|
|
|
|
*/
|
|
|
|
BlockJob *block_job_next(BlockJob *job);
|
|
|
|
|
2016-07-05 16:28:54 +02:00
|
|
|
/**
|
|
|
|
* block_job_get:
|
|
|
|
* @id: The id of the block job.
|
|
|
|
*
|
|
|
|
* Get the block job identified by @id (which must not be %NULL).
|
|
|
|
*
|
|
|
|
* Returns the requested job, or %NULL if it doesn't exist.
|
|
|
|
*/
|
|
|
|
BlockJob *block_job_get(const char *id);
|
|
|
|
|
2016-10-28 09:08:04 +02:00
|
|
|
/**
|
|
|
|
* block_job_add_bdrv:
|
|
|
|
* @job: A block job
|
2017-01-17 11:56:42 +01:00
|
|
|
* @name: The name to assign to the new BdrvChild
|
2016-10-28 09:08:04 +02:00
|
|
|
* @bs: A BlockDriverState that is involved in @job
|
2017-01-17 11:56:42 +01:00
|
|
|
* @perm, @shared_perm: Permissions to request on the node
|
2016-10-28 09:08:04 +02:00
|
|
|
*
|
|
|
|
* Add @bs to the list of BlockDriverState that are involved in
|
|
|
|
* @job. This means that all operations will be blocked on @bs while
|
|
|
|
* @job exists.
|
|
|
|
*/
|
2017-01-17 11:56:42 +01:00
|
|
|
int block_job_add_bdrv(BlockJob *job, const char *name, BlockDriverState *bs,
|
|
|
|
uint64_t perm, uint64_t shared_perm, Error **errp);
|
2016-10-28 09:08:04 +02:00
|
|
|
|
2017-02-28 12:45:58 +01:00
|
|
|
/**
|
|
|
|
* block_job_remove_all_bdrv:
|
|
|
|
* @job: The block job
|
|
|
|
*
|
|
|
|
* Remove all BlockDriverStates from the list of nodes that are involved in the
|
|
|
|
* job. This removes the blockers added with block_job_add_bdrv().
|
|
|
|
*/
|
|
|
|
void block_job_remove_all_bdrv(BlockJob *job);
|
|
|
|
|
2012-09-28 17:22:47 +02:00
|
|
|
/**
|
|
|
|
* block_job_set_speed:
|
|
|
|
* @job: The job to set the speed for.
|
|
|
|
* @speed: The new value
|
|
|
|
* @errp: Error object.
|
|
|
|
*
|
|
|
|
* Set a rate-limiting parameter for the job; the actual meaning may
|
|
|
|
* vary depending on the job type.
|
|
|
|
*/
|
|
|
|
void block_job_set_speed(BlockJob *job, int64_t speed, Error **errp);
|
|
|
|
|
2016-11-08 07:50:37 +01:00
|
|
|
/**
|
|
|
|
* block_job_start:
|
|
|
|
* @job: A job that has not yet been started.
|
|
|
|
*
|
|
|
|
* Begins execution of a block job.
|
|
|
|
* Takes ownership of one reference to the job object.
|
|
|
|
*/
|
|
|
|
void block_job_start(BlockJob *job);
|
|
|
|
|
2012-09-28 17:22:47 +02:00
|
|
|
/**
|
|
|
|
* block_job_cancel:
|
|
|
|
* @job: The job to be canceled.
|
block/mirror: change the semantic of 'force' of block-job-cancel
When doing drive mirror to a low speed shared storage, if there was heavy
BLK IO write workload in VM after the 'ready' event, drive mirror block job
can't be canceled immediately, it would keep running until the heavy BLK IO
workload stopped in the VM.
Libvirt depends on the current block-job-cancel semantics, which is that
when used without a flag after the 'ready' event, the command blocks
until data is in sync. However, these semantics are awkward in other
situations, for example, people may use drive mirror for realtime
backups while still wanting to use block live migration. Libvirt cannot
start a block live migration while another drive mirror is in progress,
but the user would rather abandon the backup attempt as broken and
proceed with the live migration than be stuck waiting for the current
drive mirror backup to finish.
The drive-mirror command already includes a 'force' flag, which libvirt
does not use, although it documented the flag as only being useful to
quit a job which is paused. However, since quitting a paused job has
the same effect as abandoning a backup in a non-paused job (namely, the
destination file is not in sync, and the command completes immediately),
we can just improve the documentation to make the force flag obviously
useful.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Jeff Cody <jcody@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>
Cc: Max Reitz <mreitz@redhat.com>
Cc: Eric Blake <eblake@redhat.com>
Cc: John Snow <jsnow@redhat.com>
Reported-by: Huaitong Han <huanhuaitong@didichuxing.com>
Signed-off-by: Huaitong Han <huanhuaitong@didichuxing.com>
Signed-off-by: Liang Li <liliangleo@didichuxing.com>
Signed-off-by: Jeff Cody <jcody@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-03-13 13:12:16 +01:00
|
|
|
* @force: Quit a job without waiting for data to be in sync.
|
2012-09-28 17:22:47 +02:00
|
|
|
*
|
|
|
|
* Asynchronously cancel the specified job.
|
|
|
|
*/
|
block/mirror: change the semantic of 'force' of block-job-cancel
When doing drive mirror to a low speed shared storage, if there was heavy
BLK IO write workload in VM after the 'ready' event, drive mirror block job
can't be canceled immediately, it would keep running until the heavy BLK IO
workload stopped in the VM.
Libvirt depends on the current block-job-cancel semantics, which is that
when used without a flag after the 'ready' event, the command blocks
until data is in sync. However, these semantics are awkward in other
situations, for example, people may use drive mirror for realtime
backups while still wanting to use block live migration. Libvirt cannot
start a block live migration while another drive mirror is in progress,
but the user would rather abandon the backup attempt as broken and
proceed with the live migration than be stuck waiting for the current
drive mirror backup to finish.
The drive-mirror command already includes a 'force' flag, which libvirt
does not use, although it documented the flag as only being useful to
quit a job which is paused. However, since quitting a paused job has
the same effect as abandoning a backup in a non-paused job (namely, the
destination file is not in sync, and the command completes immediately),
we can just improve the documentation to make the force flag obviously
useful.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Jeff Cody <jcody@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>
Cc: Max Reitz <mreitz@redhat.com>
Cc: Eric Blake <eblake@redhat.com>
Cc: John Snow <jsnow@redhat.com>
Reported-by: Huaitong Han <huanhuaitong@didichuxing.com>
Signed-off-by: Huaitong Han <huanhuaitong@didichuxing.com>
Signed-off-by: Liang Li <liliangleo@didichuxing.com>
Signed-off-by: Jeff Cody <jcody@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-03-13 13:12:16 +01:00
|
|
|
void block_job_cancel(BlockJob *job, bool force);
|
2012-09-28 17:22:47 +02:00
|
|
|
|
2012-10-18 16:49:21 +02:00
|
|
|
/**
|
|
|
|
* block_job_complete:
|
|
|
|
* @job: The job to be completed.
|
|
|
|
* @errp: Error object.
|
|
|
|
*
|
|
|
|
* Asynchronously complete the specified job.
|
|
|
|
*/
|
|
|
|
void block_job_complete(BlockJob *job, Error **errp);
|
|
|
|
|
2018-03-10 09:27:43 +01:00
|
|
|
|
|
|
|
/**
|
|
|
|
* block_job_finalize:
|
|
|
|
* @job: The job to fully commit and finish.
|
|
|
|
* @errp: Error object.
|
|
|
|
*
|
|
|
|
* For jobs that have finished their work and are pending
|
|
|
|
* awaiting explicit acknowledgement to commit their work,
|
|
|
|
* This will commit that work.
|
|
|
|
*
|
|
|
|
* FIXME: Make the below statement universally true:
|
|
|
|
* For jobs that support the manual workflow mode, all graph
|
|
|
|
* changes that occur as a result will occur after this command
|
|
|
|
* and before a successful reply.
|
|
|
|
*/
|
|
|
|
void block_job_finalize(BlockJob *job, Error **errp);
|
|
|
|
|
2018-03-10 09:27:36 +01:00
|
|
|
/**
|
|
|
|
* block_job_dismiss:
|
|
|
|
* @job: The job to be dismissed.
|
|
|
|
* @errp: Error object.
|
|
|
|
*
|
|
|
|
* Remove a concluded job from the query list.
|
|
|
|
*/
|
|
|
|
void block_job_dismiss(BlockJob **job, Error **errp);
|
|
|
|
|
2018-01-18 18:08:22 +01:00
|
|
|
/**
|
|
|
|
* block_job_progress_update:
|
|
|
|
* @job: The job that has made progress
|
|
|
|
* @done: How much progress the job made
|
|
|
|
*
|
|
|
|
* Updates the progress counter of the job.
|
|
|
|
*/
|
|
|
|
void block_job_progress_update(BlockJob *job, uint64_t done);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* block_job_progress_set_remaining:
|
|
|
|
* @job: The job whose expected progress end value is set
|
|
|
|
* @remaining: Expected end value of the progress counter of the job
|
|
|
|
*
|
|
|
|
* Sets the expected end value of the progress counter of a job so that a
|
|
|
|
* completion percentage can be calculated when the progress is updated.
|
|
|
|
*/
|
|
|
|
void block_job_progress_set_remaining(BlockJob *job, uint64_t remaining);
|
|
|
|
|
2012-09-28 17:22:48 +02:00
|
|
|
/**
|
|
|
|
* block_job_query:
|
|
|
|
* @job: The job to get information about.
|
|
|
|
*
|
|
|
|
* Return information about a job.
|
|
|
|
*/
|
2016-10-27 18:06:55 +02:00
|
|
|
BlockJobInfo *block_job_query(BlockJob *job, Error **errp);
|
2012-09-28 17:22:48 +02:00
|
|
|
|
2016-10-27 18:06:59 +02:00
|
|
|
/**
|
|
|
|
* block_job_user_pause:
|
|
|
|
* @job: The job to be paused.
|
|
|
|
*
|
|
|
|
* Asynchronously pause the specified job.
|
|
|
|
* Do not allow a resume until a matching call to block_job_user_resume.
|
|
|
|
*/
|
blockjobs: add block_job_verb permission table
Which commands ("verbs") are appropriate for jobs in which state is
also somewhat burdensome to keep track of.
As of this commit, it looks rather useless, but begins to look more
interesting the more states we add to the STM table.
A recurring theme is that no verb will apply to an 'undefined' job.
Further, it's not presently possible to restrict the "pause" or "resume"
verbs any more than they are in this commit because of the asynchronous
nature of how jobs enter the PAUSED state; justifications for some
seemingly erroneous applications are given below.
=====
Verbs
=====
Cancel: Any state except undefined.
Pause: Any state except undefined;
'created': Requests that the job pauses as it starts.
'running': Normal usage. (PAUSED)
'paused': The job may be paused for internal reasons,
but the user may wish to force an indefinite
user-pause, so this is allowed.
'ready': Normal usage. (STANDBY)
'standby': Same logic as above.
Resume: Any state except undefined;
'created': Will lift a user's pause-on-start request.
'running': Will lift a pause request before it takes effect.
'paused': Normal usage.
'ready': Will lift a pause request before it takes effect.
'standby': Normal usage.
Set-speed: Any state except undefined, though ready may not be meaningful.
Complete: Only a 'ready' job may accept a complete request.
=======
Changes
=======
(1)
To facilitate "nice" error checking, all five major block-job verb
interfaces in blockjob.c now support an errp parameter:
- block_job_user_cancel is added as a new interface.
- block_job_user_pause gains an errp paramter
- block_job_user_resume gains an errp parameter
- block_job_set_speed already had an errp parameter.
- block_job_complete already had an errp parameter.
(2)
block-job-pause and block-job-resume will no longer no-op when trying
to pause an already paused job, or trying to resume a job that isn't
paused. These functions will now report that they did not perform the
action requested because it was not possible.
iotests have been adjusted to address this new behavior.
(3)
block-job-complete doesn't worry about checking !block_job_started,
because the permission table guards against this.
(4)
test-bdrv-drain's job implementation needs to announce that it is
'ready' now, in order to be completed.
Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-03-10 09:27:32 +01:00
|
|
|
void block_job_user_pause(BlockJob *job, Error **errp);
|
2016-10-27 18:06:59 +02:00
|
|
|
|
|
|
|
/**
|
|
|
|
* block_job_paused:
|
|
|
|
* @job: The job to query.
|
|
|
|
*
|
|
|
|
* Returns true if the job is user-paused.
|
|
|
|
*/
|
|
|
|
bool block_job_user_paused(BlockJob *job);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* block_job_user_resume:
|
|
|
|
* @job: The job to be resumed.
|
|
|
|
*
|
|
|
|
* Resume the specified job.
|
|
|
|
* Must be paired with a preceding block_job_user_pause.
|
|
|
|
*/
|
blockjobs: add block_job_verb permission table
Which commands ("verbs") are appropriate for jobs in which state is
also somewhat burdensome to keep track of.
As of this commit, it looks rather useless, but begins to look more
interesting the more states we add to the STM table.
A recurring theme is that no verb will apply to an 'undefined' job.
Further, it's not presently possible to restrict the "pause" or "resume"
verbs any more than they are in this commit because of the asynchronous
nature of how jobs enter the PAUSED state; justifications for some
seemingly erroneous applications are given below.
=====
Verbs
=====
Cancel: Any state except undefined.
Pause: Any state except undefined;
'created': Requests that the job pauses as it starts.
'running': Normal usage. (PAUSED)
'paused': The job may be paused for internal reasons,
but the user may wish to force an indefinite
user-pause, so this is allowed.
'ready': Normal usage. (STANDBY)
'standby': Same logic as above.
Resume: Any state except undefined;
'created': Will lift a user's pause-on-start request.
'running': Will lift a pause request before it takes effect.
'paused': Normal usage.
'ready': Will lift a pause request before it takes effect.
'standby': Normal usage.
Set-speed: Any state except undefined, though ready may not be meaningful.
Complete: Only a 'ready' job may accept a complete request.
=======
Changes
=======
(1)
To facilitate "nice" error checking, all five major block-job verb
interfaces in blockjob.c now support an errp parameter:
- block_job_user_cancel is added as a new interface.
- block_job_user_pause gains an errp paramter
- block_job_user_resume gains an errp parameter
- block_job_set_speed already had an errp parameter.
- block_job_complete already had an errp parameter.
(2)
block-job-pause and block-job-resume will no longer no-op when trying
to pause an already paused job, or trying to resume a job that isn't
paused. These functions will now report that they did not perform the
action requested because it was not possible.
iotests have been adjusted to address this new behavior.
(3)
block-job-complete doesn't worry about checking !block_job_started,
because the permission table guards against this.
(4)
test-bdrv-drain's job implementation needs to announce that it is
'ready' now, in order to be completed.
Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-03-10 09:27:32 +01:00
|
|
|
void block_job_user_resume(BlockJob *job, Error **errp);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* block_job_user_cancel:
|
|
|
|
* @job: The job to be cancelled.
|
block/mirror: change the semantic of 'force' of block-job-cancel
When doing drive mirror to a low speed shared storage, if there was heavy
BLK IO write workload in VM after the 'ready' event, drive mirror block job
can't be canceled immediately, it would keep running until the heavy BLK IO
workload stopped in the VM.
Libvirt depends on the current block-job-cancel semantics, which is that
when used without a flag after the 'ready' event, the command blocks
until data is in sync. However, these semantics are awkward in other
situations, for example, people may use drive mirror for realtime
backups while still wanting to use block live migration. Libvirt cannot
start a block live migration while another drive mirror is in progress,
but the user would rather abandon the backup attempt as broken and
proceed with the live migration than be stuck waiting for the current
drive mirror backup to finish.
The drive-mirror command already includes a 'force' flag, which libvirt
does not use, although it documented the flag as only being useful to
quit a job which is paused. However, since quitting a paused job has
the same effect as abandoning a backup in a non-paused job (namely, the
destination file is not in sync, and the command completes immediately),
we can just improve the documentation to make the force flag obviously
useful.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Jeff Cody <jcody@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>
Cc: Max Reitz <mreitz@redhat.com>
Cc: Eric Blake <eblake@redhat.com>
Cc: John Snow <jsnow@redhat.com>
Reported-by: Huaitong Han <huanhuaitong@didichuxing.com>
Signed-off-by: Huaitong Han <huanhuaitong@didichuxing.com>
Signed-off-by: Liang Li <liliangleo@didichuxing.com>
Signed-off-by: Jeff Cody <jcody@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-03-13 13:12:16 +01:00
|
|
|
* @force: Quit a job without waiting for data to be in sync.
|
blockjobs: add block_job_verb permission table
Which commands ("verbs") are appropriate for jobs in which state is
also somewhat burdensome to keep track of.
As of this commit, it looks rather useless, but begins to look more
interesting the more states we add to the STM table.
A recurring theme is that no verb will apply to an 'undefined' job.
Further, it's not presently possible to restrict the "pause" or "resume"
verbs any more than they are in this commit because of the asynchronous
nature of how jobs enter the PAUSED state; justifications for some
seemingly erroneous applications are given below.
=====
Verbs
=====
Cancel: Any state except undefined.
Pause: Any state except undefined;
'created': Requests that the job pauses as it starts.
'running': Normal usage. (PAUSED)
'paused': The job may be paused for internal reasons,
but the user may wish to force an indefinite
user-pause, so this is allowed.
'ready': Normal usage. (STANDBY)
'standby': Same logic as above.
Resume: Any state except undefined;
'created': Will lift a user's pause-on-start request.
'running': Will lift a pause request before it takes effect.
'paused': Normal usage.
'ready': Will lift a pause request before it takes effect.
'standby': Normal usage.
Set-speed: Any state except undefined, though ready may not be meaningful.
Complete: Only a 'ready' job may accept a complete request.
=======
Changes
=======
(1)
To facilitate "nice" error checking, all five major block-job verb
interfaces in blockjob.c now support an errp parameter:
- block_job_user_cancel is added as a new interface.
- block_job_user_pause gains an errp paramter
- block_job_user_resume gains an errp parameter
- block_job_set_speed already had an errp parameter.
- block_job_complete already had an errp parameter.
(2)
block-job-pause and block-job-resume will no longer no-op when trying
to pause an already paused job, or trying to resume a job that isn't
paused. These functions will now report that they did not perform the
action requested because it was not possible.
iotests have been adjusted to address this new behavior.
(3)
block-job-complete doesn't worry about checking !block_job_started,
because the permission table guards against this.
(4)
test-bdrv-drain's job implementation needs to announce that it is
'ready' now, in order to be completed.
Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-03-10 09:27:32 +01:00
|
|
|
*
|
|
|
|
* Cancels the specified job, but may refuse to do so if the
|
|
|
|
* operation isn't currently meaningful.
|
|
|
|
*/
|
block/mirror: change the semantic of 'force' of block-job-cancel
When doing drive mirror to a low speed shared storage, if there was heavy
BLK IO write workload in VM after the 'ready' event, drive mirror block job
can't be canceled immediately, it would keep running until the heavy BLK IO
workload stopped in the VM.
Libvirt depends on the current block-job-cancel semantics, which is that
when used without a flag after the 'ready' event, the command blocks
until data is in sync. However, these semantics are awkward in other
situations, for example, people may use drive mirror for realtime
backups while still wanting to use block live migration. Libvirt cannot
start a block live migration while another drive mirror is in progress,
but the user would rather abandon the backup attempt as broken and
proceed with the live migration than be stuck waiting for the current
drive mirror backup to finish.
The drive-mirror command already includes a 'force' flag, which libvirt
does not use, although it documented the flag as only being useful to
quit a job which is paused. However, since quitting a paused job has
the same effect as abandoning a backup in a non-paused job (namely, the
destination file is not in sync, and the command completes immediately),
we can just improve the documentation to make the force flag obviously
useful.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Jeff Cody <jcody@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>
Cc: Max Reitz <mreitz@redhat.com>
Cc: Eric Blake <eblake@redhat.com>
Cc: John Snow <jsnow@redhat.com>
Reported-by: Huaitong Han <huanhuaitong@didichuxing.com>
Signed-off-by: Huaitong Han <huanhuaitong@didichuxing.com>
Signed-off-by: Liang Li <liliangleo@didichuxing.com>
Signed-off-by: Jeff Cody <jcody@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-03-13 13:12:16 +01:00
|
|
|
void block_job_user_cancel(BlockJob *job, bool force, Error **errp);
|
2016-10-27 18:06:59 +02:00
|
|
|
|
2012-09-28 17:22:47 +02:00
|
|
|
/**
|
|
|
|
* block_job_cancel_sync:
|
|
|
|
* @job: The job to be canceled.
|
|
|
|
*
|
|
|
|
* Synchronously cancel the job. The completion callback is called
|
|
|
|
* before the function returns. The job may actually complete
|
|
|
|
* instead of canceling itself; the circumstances under which this
|
|
|
|
* happens depend on the kind of job that is active.
|
|
|
|
*
|
|
|
|
* Returns the return value from the job if the job actually completed
|
|
|
|
* during the call, or -ECANCELED if it was canceled.
|
|
|
|
*/
|
|
|
|
int block_job_cancel_sync(BlockJob *job);
|
|
|
|
|
2016-04-08 18:26:37 +02:00
|
|
|
/**
|
|
|
|
* block_job_cancel_sync_all:
|
|
|
|
*
|
|
|
|
* Synchronously cancels all jobs using block_job_cancel_sync().
|
|
|
|
*/
|
|
|
|
void block_job_cancel_sync_all(void);
|
|
|
|
|
2014-10-24 15:57:33 +02:00
|
|
|
/**
|
|
|
|
* block_job_complete_sync:
|
|
|
|
* @job: The job to be completed.
|
|
|
|
* @errp: Error object which may be set by block_job_complete(); this is not
|
|
|
|
* necessarily set on every error, the job return value has to be
|
|
|
|
* checked as well.
|
|
|
|
*
|
|
|
|
* Synchronously complete the job. The completion callback is called before the
|
|
|
|
* function returns, unless it is NULL (which is permissible when using this
|
|
|
|
* function).
|
|
|
|
*
|
|
|
|
* Returns the return value from the job.
|
|
|
|
*/
|
|
|
|
int block_job_complete_sync(BlockJob *job, Error **errp);
|
|
|
|
|
block: introduce block job error
The following behaviors are possible:
'report': The behavior is the same as in 1.1. An I/O error,
respectively during a read or a write, will complete the job immediately
with an error code.
'ignore': An I/O error, respectively during a read or a write, will be
ignored. For streaming, the job will complete with an error and the
backing file will be left in place. For mirroring, the sector will be
marked again as dirty and re-examined later.
'stop': The job will be paused and the job iostatus will be set to
failed or nospace, while the VM will keep running. This can only be
specified if the block device has rerror=stop and werror=stop or enospc.
'enospc': Behaves as 'stop' for ENOSPC errors, 'report' for others.
In all cases, even for 'report', the I/O error is reported as a QMP
event BLOCK_JOB_ERROR, with the same arguments as BLOCK_IO_ERROR.
It is possible that while stopping the VM a BLOCK_IO_ERROR event will be
reported and will clobber the event from BLOCK_JOB_ERROR, or vice versa.
This is not really avoidable since stopping the VM completes all pending
I/O requests. In fact, it is already possible now that a series of
BLOCK_IO_ERROR events are reported with rerror=stop, because vm_stop
calls bdrv_drain_all and this can generate further errors.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2012-09-28 17:22:58 +02:00
|
|
|
/**
|
|
|
|
* block_job_iostatus_reset:
|
|
|
|
* @job: The job whose I/O status should be reset.
|
|
|
|
*
|
2012-10-18 16:49:27 +02:00
|
|
|
* Reset I/O status on @job and on BlockDriverState objects it uses,
|
2016-05-30 11:28:11 +02:00
|
|
|
* other than job->blk.
|
block: introduce block job error
The following behaviors are possible:
'report': The behavior is the same as in 1.1. An I/O error,
respectively during a read or a write, will complete the job immediately
with an error code.
'ignore': An I/O error, respectively during a read or a write, will be
ignored. For streaming, the job will complete with an error and the
backing file will be left in place. For mirroring, the sector will be
marked again as dirty and re-examined later.
'stop': The job will be paused and the job iostatus will be set to
failed or nospace, while the VM will keep running. This can only be
specified if the block device has rerror=stop and werror=stop or enospc.
'enospc': Behaves as 'stop' for ENOSPC errors, 'report' for others.
In all cases, even for 'report', the I/O error is reported as a QMP
event BLOCK_JOB_ERROR, with the same arguments as BLOCK_IO_ERROR.
It is possible that while stopping the VM a BLOCK_IO_ERROR event will be
reported and will clobber the event from BLOCK_JOB_ERROR, or vice versa.
This is not really avoidable since stopping the VM completes all pending
I/O requests. In fact, it is already possible now that a series of
BLOCK_IO_ERROR events are reported with rerror=stop, because vm_stop
calls bdrv_drain_all and this can generate further errors.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2012-09-28 17:22:58 +02:00
|
|
|
*/
|
|
|
|
void block_job_iostatus_reset(BlockJob *job);
|
|
|
|
|
2015-11-06 00:13:15 +01:00
|
|
|
/**
|
|
|
|
* block_job_txn_new:
|
|
|
|
*
|
|
|
|
* Allocate and return a new block job transaction. Jobs can be added to the
|
|
|
|
* transaction using block_job_txn_add_job().
|
|
|
|
*
|
|
|
|
* The transaction is automatically freed when the last job completes or is
|
|
|
|
* cancelled.
|
|
|
|
*
|
|
|
|
* All jobs in the transaction either complete successfully or fail/cancel as a
|
|
|
|
* group. Jobs wait for each other before completing. Cancelling one job
|
|
|
|
* cancels all jobs in the transaction.
|
|
|
|
*/
|
|
|
|
BlockJobTxn *block_job_txn_new(void);
|
|
|
|
|
2017-06-15 08:47:33 +02:00
|
|
|
/**
|
|
|
|
* block_job_ref:
|
|
|
|
*
|
|
|
|
* Add a reference to BlockJob refcnt, it will be decreased with
|
|
|
|
* block_job_unref, and then be freed if it comes to be the last
|
|
|
|
* reference.
|
|
|
|
*/
|
|
|
|
void block_job_ref(BlockJob *job);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* block_job_unref:
|
|
|
|
*
|
|
|
|
* Release a reference that was previously acquired with block_job_ref
|
|
|
|
* or block_job_create. If it's the last reference to the object, it will be
|
|
|
|
* freed.
|
|
|
|
*/
|
|
|
|
void block_job_unref(BlockJob *job);
|
|
|
|
|
2015-11-06 00:13:15 +01:00
|
|
|
/**
|
|
|
|
* block_job_txn_unref:
|
|
|
|
*
|
|
|
|
* Release a reference that was previously acquired with block_job_txn_add_job
|
|
|
|
* or block_job_txn_new. If it's the last reference to the object, it will be
|
|
|
|
* freed.
|
|
|
|
*/
|
|
|
|
void block_job_txn_unref(BlockJobTxn *txn);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* block_job_txn_add_job:
|
|
|
|
* @txn: The transaction (may be NULL)
|
|
|
|
* @job: Job to add to the transaction
|
|
|
|
*
|
|
|
|
* Add @job to the transaction. The @job must not already be in a transaction.
|
|
|
|
* The caller must call either block_job_txn_unref() or block_job_completed()
|
|
|
|
* to release the reference that is automatically grabbed here.
|
|
|
|
*/
|
|
|
|
void block_job_txn_add_job(BlockJobTxn *txn, BlockJob *job);
|
|
|
|
|
2016-10-27 18:06:55 +02:00
|
|
|
/**
|
|
|
|
* block_job_is_internal:
|
|
|
|
* @job: The job to determine if it is user-visible or not.
|
|
|
|
*
|
|
|
|
* Returns true if the job should not be visible to the management layer.
|
|
|
|
*/
|
|
|
|
bool block_job_is_internal(BlockJob *job);
|
|
|
|
|
2018-01-19 15:54:40 +01:00
|
|
|
/**
|
|
|
|
* block_job_driver:
|
|
|
|
*
|
|
|
|
* Returns the driver associated with a block job.
|
|
|
|
*/
|
|
|
|
const BlockJobDriver *block_job_driver(BlockJob *job);
|
|
|
|
|
2012-09-28 17:22:47 +02:00
|
|
|
#endif
|