From: John Snow <jsnow@redhat.com>
To: Eric Blake <eblake@redhat.com>, qemu-block@nongnu.org
Cc: qemu-devel@nongnu.org, stefanha@redhat.com
Subject: Re: [Qemu-devel] [PATCH] docs: update bitmaps.md
Date: Tue, 10 Nov 2015 18:18:54 -0500 [thread overview]
Message-ID: <56427B5E.6070604@redhat.com> (raw)
In-Reply-To: <5642792F.8070601@redhat.com>
On 11/10/2015 06:09 PM, Eric Blake wrote:
> On 11/10/2015 04:00 PM, John Snow wrote:
>> Include new error handling scenarios for 2.5.
>>
>> Signed-off-by: John Snow <jsnow@redhat.com>
>> ---
>> docs/bitmaps.md | 157 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 157 insertions(+)
>>
>> diff --git a/docs/bitmaps.md b/docs/bitmaps.md
>> index 9fd8ea6..a2e8d51 100644
>> --- a/docs/bitmaps.md
>> +++ b/docs/bitmaps.md
>> @@ -19,12 +19,20 @@ which is included at the end of this document.
>> * A dirty bitmap's name is unique to the node, but bitmaps attached to different
>> nodes can share the same name.
>>
>> +* Dirty bitmaps created for internal use by QEMU may be anonymous and have no
>> + name, but any user-created bitmaps may not be. There can be any number of
>> + anonymous bitmaps per node.
>
> may not be what? Maybe:
>
> Dirty bitmaps ... have no name, but any user-created bitmaps will have a
> name. There can be...
>
>
>> +
>> +### Grouped Completion Mode
>> +
>
>> + * Later, QEMU sends notice that the second job has errored out,
>> + but that the first job was also cancelled:
>> + ```json
>> + { "timestamp": { "seconds": 1447193702, "microseconds": 632377 },
>> + "data": { "device": "drive1", "action": "report",
>> + "operation": "read" },
>> + "event": "BLOCK_JOB_ERROR" }
>> + ```
>> +
>> + ```json
>> + { "timestamp": { "seconds": 1447193702, "microseconds": 640074 },
>> + "data": { "speed": 0, "offset": 0, "len": 67108864,
>> + "error": "Input/output error",
>> + "device": "drive1", "type": "backup" },
>> + "event": "BLOCK_JOB_COMPLETED" }
>> + ```
>
> So we get both an error and a completion notice on failed jobs? I guess
> it's because you can configure jobs to report errors but continue on, so
> the error notification alone doesn't say whether the job ends.
>
Not a design choice of mine; that's just what already happens when a
block job fails. You get the error notice *AND* the "completion" notice
with the error field set.
>> +
>> + ```json
>> + { "timestamp": { "seconds": 1447193702, "microseconds": 640163 },
>> + "data": { "device": "drive0", "type": "backup", "speed": 0,
>> + "len": 67108864, "offset": 16777216 },
>> + "event": "BLOCK_JOB_CANCELLED" }
>> + ```
>> +
>
> Thanks; these examples are very useful.
>
I'm glad.
> Reviewed-by: Eric Blake <eblake@redhat.com>
>
Thanks,
--js
next prev parent reply other threads:[~2015-11-10 23:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-10 23:00 [Qemu-devel] [PATCH] docs: update bitmaps.md John Snow
2015-11-10 23:09 ` Eric Blake
2015-11-10 23:18 ` John Snow [this message]
2015-11-16 3:30 ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56427B5E.6070604@redhat.com \
--to=jsnow@redhat.com \
--cc=eblake@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).