[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v9 05/11] block: allow block jobs in any arbitra
Re: [Qemu-devel] [PATCH v9 05/11] block: allow block jobs in any arbitrary node
Fri, 29 Apr 2016 09:25:00 -0600
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
On 04/04/2016 07:43 AM, Alberto Garcia wrote:
> Currently, block jobs can only be owned by root nodes. This patch
> allows block jobs to be in any arbitrary node, by making the following
> - Block jobs can now be identified by the node name of their
> BlockDriverState in addition to the device name. Since both device
> and node names live in the same namespace there's no ambiguity.
> - The "device" parameter used by all commands that operate on block
> jobs can also be a node name now.
> - The node name is used as a fallback to fill in the BlockJobInfo
> structure and all BLOCK_JOB_* events if there is no device name for
> that job.
Having more than one way to name a job might be okay for convenience,
but only if the canonical name is unambiguous. I agree with Kevin's
concern that using the device and/or node name as the canonical name of
the job is worrisome, because it locks us into having only one job with
that name at a time.
> +++ b/docs/qmp-events.txt
> @@ -92,7 +92,7 @@ Data:
> - "type": Job type (json-string; "stream" for image streaming
> "commit" for block commit)
> -- "device": Device name (json-string)
> +- "device": Device name, or node name if not present (json-string)
On the surface this sounds okay (you are promising to return a canonical
name, insofar as job canonical names are currently the node/device name
until the time that we allow job ids with multiple jobs per device) -
even if it means that you return a device name when the user started a
job based on a node name.
But I'm also worried about jobs where the node name tied to a device
changes over time (creating a snapshot, pivoting to a mirror, doing an
active commit with a pivot to the backing file - all of these are cases
where the device name stays the same, but the top node name associated
with the device differs over time). If the device name is the canonical
one, then a job started on node "A" but reported as device "D", needs to
STILL be known as job "D" even if by the end of the job node "A" is no
longer associated with device "D" (because "D" is now serving the
top-level node "B").
> @@ -1513,7 +1513,7 @@
> # the operation is actually paused. Cancelling a paused job automatically
> # resumes it.
> -# @device: the device name
> +# @device: the device or node name of the owner of the block job.
We aren't consistent on whether to use a trailing '.'. I don't care
enough to standardize on a style, so no need to respin for just that.
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Description: OpenPGP digital signature
- Re: [Qemu-devel] [PATCH v9 10/11] qemu-iotests: test overlapping block-stream operations, (continued)
- [Qemu-devel] [PATCH v9 08/11] docs: Document how to stream to an intermediate layer, Alberto Garcia, 2016/04/04
- [Qemu-devel] [PATCH v9 04/11] block: use the block job list in bdrv_close(), Alberto Garcia, 2016/04/04
- [Qemu-devel] [PATCH v9 05/11] block: allow block jobs in any arbitrary node, Alberto Garcia, 2016/04/04
- [Qemu-devel] [PATCH v9 03/11] block: use the block job list in qmp_query_block_jobs(), Alberto Garcia, 2016/04/04
- [Qemu-devel] [PATCH v9 07/11] block: Add QMP support for streaming to an intermediate layer, Alberto Garcia, 2016/04/04
- Re: [Qemu-devel] [PATCH v9 07/11] block: Add QMP support for streaming to an intermediate layer, Kevin Wolf, 2016/04/29
- Re: [Qemu-devel] [PATCH v9 07/11] block: Add QMP support for streaming to an intermediate layer, Eric Blake, 2016/04/29
- [Qemu-devel] [PATCH v9 09/11] qemu-iotests: test streaming to an intermediate layer, Alberto Garcia, 2016/04/04