From: Luiz Capitulino <lcapitulino@redhat.com>
To: kwolf@redhat.com
Cc: fromani@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com
Subject: Re: [Qemu-devel] [PATCH] block: extend BLOCK_IO_ERROR event with nospace indicator
Date: Mon, 8 Sep 2014 10:42:17 -0400 [thread overview]
Message-ID: <20140908104217.48f2354a@redhat.com> (raw)
In-Reply-To: <20140829160727.69f66ecd@redhat.com>
On Fri, 29 Aug 2014 16:07:27 -0400
Luiz Capitulino <lcapitulino@redhat.com> wrote:
> Management software, such as RHEV's vdsm, want to be able to allocate
> disk space on demand. The basic use case is to start a VM with a small
> disk and then the disk is enlarged when QEMU hits a ENOSPC condition.
>
> To this end, the management software has to be notified when QEMU
> encounters ENOSPC. The solution implemented by this commit is simple:
> it extends the BLOCK_IO_ERROR with a 'nospace' key, which is true
> when QEMU is stopped due to ENOSPC.
>
> Note that support for querying this event is already present in
> query-block by means of the 'io-status' key. Also, the new 'nospace'
> BLOCK_IO_ERROR field shares the same semantics with 'io-status',
> which basically means that werror= has to be set to either
> 'stop' or 'enospc' to enable 'nospace'.
>
> Finally, this commit also updates the 'io-status' key doc in the
> schema with a list of supported device models.
>
> Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Kevin, are you going to take this via block layer tree?
> ---
>
> Three important observations:
>
> 1. We've talked with oVirt and OpenStack folks. oVirt folks say that
> this implementation is enough for their use-case. OpenStack don't
> need this feature
>
> 2. While testing this with a raw image on a (smaller) ext2 file mounted
> via the loopback device, I get half "Invalid argument" I/O errors and
> half "No space" errors". This means that half of the BLOCK_IO_ERROR
> events that are emitted for this test-case will have nospace=false
> and the other half nospace=true. I don't know why I'm getting those
> "Invalid argument" errors, can anyone of the block layer comment
> on this? I don't get that with a qcow2 image (I get nospace=true for
> all events)
>
> 3. I think this should go via block tree
>
> block.c | 22 ++++++++++++++--------
> qapi/block-core.json | 8 +++++++-
> 2 files changed, 21 insertions(+), 9 deletions(-)
>
> diff --git a/block.c b/block.c
> index 1df13ac..b334e35 100644
> --- a/block.c
> +++ b/block.c
> @@ -3632,6 +3632,18 @@ BlockErrorAction bdrv_get_error_action(BlockDriverState *bs, bool is_read, int e
> }
> }
>
> +static void send_qmp_error_event(BlockDriverState *bs,
> + BlockErrorAction action,
> + bool is_read, int error)
> +{
> + BlockErrorAction ac;
> +
> + ac = is_read ? IO_OPERATION_TYPE_READ : IO_OPERATION_TYPE_WRITE;
> + qapi_event_send_block_io_error(bdrv_get_device_name(bs), ac, action,
> + bdrv_iostatus_is_enabled(bs),
> + error == ENOSPC, &error_abort);
> +}
> +
> /* This is done by device models because, while the block layer knows
> * about the error, it does not know whether an operation comes from
> * the device or the block layer (from a job, for example).
> @@ -3657,16 +3669,10 @@ void bdrv_error_action(BlockDriverState *bs, BlockErrorAction action,
> * also ensures that the STOP/RESUME pair of events is emitted.
> */
> qemu_system_vmstop_request_prepare();
> - qapi_event_send_block_io_error(bdrv_get_device_name(bs),
> - is_read ? IO_OPERATION_TYPE_READ :
> - IO_OPERATION_TYPE_WRITE,
> - action, &error_abort);
> + send_qmp_error_event(bs, action, is_read, error);
> qemu_system_vmstop_request(RUN_STATE_IO_ERROR);
> } else {
> - qapi_event_send_block_io_error(bdrv_get_device_name(bs),
> - is_read ? IO_OPERATION_TYPE_READ :
> - IO_OPERATION_TYPE_WRITE,
> - action, &error_abort);
> + send_qmp_error_event(bs, action, is_read, error);
> }
> }
>
> diff --git a/qapi/block-core.json b/qapi/block-core.json
> index fb74c56..567e0a6 100644
> --- a/qapi/block-core.json
> +++ b/qapi/block-core.json
> @@ -336,6 +336,7 @@
> #
> # @io-status: #optional @BlockDeviceIoStatus. Only present if the device
> # supports it and the VM is configured to stop on errors
> +# (supported device models: virtio-blk, ide, scsi-disk)
> #
> # @inserted: #optional @BlockDeviceInfo describing the device if media is
> # present
> @@ -1569,6 +1570,11 @@
> #
> # @action: action that has been taken
> #
> +# @nospace: #optional true if I/O error was caused due to a no-space
> +# condition. This key is only present if query-block's
> +# io-status is present, please see query-block documentation
> +# for more information (since: 2.2)
> +#
> # Note: If action is "stop", a STOP event will eventually follow the
> # BLOCK_IO_ERROR event
> #
> @@ -1576,7 +1582,7 @@
> ##
> { 'event': 'BLOCK_IO_ERROR',
> 'data': { 'device': 'str', 'operation': 'IoOperationType',
> - 'action': 'BlockErrorAction' } }
> + 'action': 'BlockErrorAction', '*nospace': 'bool' } }
>
> ##
> # @BLOCK_JOB_COMPLETED
next prev parent reply other threads:[~2014-09-08 14:42 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-29 20:07 [Qemu-devel] [PATCH] block: extend BLOCK_IO_ERROR event with nospace indicator Luiz Capitulino
2014-08-29 20:33 ` Eric Blake
2014-09-08 14:42 ` Luiz Capitulino [this message]
2014-09-08 15:33 ` Kevin Wolf
2014-09-08 16:57 ` Luiz Capitulino
2014-09-09 8:27 ` Kevin Wolf
2014-09-09 12:37 ` Eric Blake
2014-09-09 12:43 ` Luiz Capitulino
2014-09-09 12:53 ` Eric Blake
2014-09-09 13:23 ` Kevin Wolf
2014-09-09 13:42 ` Luiz Capitulino
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=20140908104217.48f2354a@redhat.com \
--to=lcapitulino@redhat.com \
--cc=armbru@redhat.com \
--cc=fromani@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-devel@nongnu.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.