From: Luiz Capitulino <lcapitulino@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: kwolf@redhat.com, zwu.kernel@gmail.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 1/6] block: Keep track of devices' I/O status
Date: Fri, 23 Sep 2011 11:01:00 -0300 [thread overview]
Message-ID: <20110923110100.1f72f0c6@doriath> (raw)
In-Reply-To: <m3hb43snlv.fsf@blackfin.pond.sub.org>
On Fri, 23 Sep 2011 09:51:24 +0200
Markus Armbruster <armbru@redhat.com> wrote:
> Luiz Capitulino <lcapitulino@redhat.com> writes:
>
> > This commit adds support to the BlockDriverState type to keep track
> > of devices' I/O status.
> >
> > There are three possible status: BDRV_IOS_OK (no error), BDRV_IOS_ENOSPC
> > (no space error) and BDRV_IOS_FAILED (any other error). The distinction
> > between no space and other errors is important because a management
> > application may want to watch for no space in order to extend the
> > space assigned to the VM and put it to run again.
> >
> > Qemu devices supporting the I/O status feature have to enable it
> > explicitly by calling bdrv_iostatus_enable() _and_ have to be
> > configured to stop the VM on errors (ie. werror=stop|enospc or
> > rerror=stop).
> >
> > In case of multiple errors being triggered in sequence only the first
> > one is stored. The I/O status is always reset to BDRV_IOS_OK when the
> > 'cont' command is issued.
> >
> > Next commits will add support to some devices and extend the
> > query-block/info block commands to return the I/O status information.
> >
> > Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
> > ---
> > block.c | 32 ++++++++++++++++++++++++++++++++
> > block.h | 9 +++++++++
> > block_int.h | 1 +
> > monitor.c | 6 ++++++
> > 4 files changed, 48 insertions(+), 0 deletions(-)
> >
> > diff --git a/block.c b/block.c
> > index e3fe97f..fbd90b4 100644
> > --- a/block.c
> > +++ b/block.c
> > @@ -221,6 +221,7 @@ BlockDriverState *bdrv_new(const char *device_name)
> > if (device_name[0] != '\0') {
> > QTAILQ_INSERT_TAIL(&bdrv_states, bs, list);
> > }
> > + bs->iostatus = BDRV_IOS_INVAL;
> > return bs;
> > }
> >
> > @@ -3181,6 +3182,37 @@ int bdrv_in_use(BlockDriverState *bs)
> > return bs->in_use;
> > }
> >
> > +void bdrv_iostatus_enable(BlockDriverState *bs)
> > +{
> > + assert(bs->iostatus == BDRV_IOS_INVAL);
> > + bs->iostatus = BDRV_IOS_OK;
> > +}
>
> bdrv_new() creates the BDS with I/O status tracking disabled. Devices
> that do tracking declare that by calling this function during
> initialization. Enables tracking if the BDS has suitable on_write_error
> and on_read_error.
>
> If a device gets hot unplugged, tracking remains enabled. If the BDS
> then gets reused with a device that doesn't do tracking, I/O status
> becomes incorrect. Can't happen right now, because we automatically
> delete the BDS on hot unplug, but it's a trap.
>
> Suggest to disable tracking in bdrv_detach_dev() or bdrv_attach_dev().
Ok, and in bdrv_close() as Zhi Yong said.
> > +
> > +/* The I/O status is only enabled if the drive explicitly
> > + * enables it _and_ the VM is configured to stop on errors */
> > +bool bdrv_iostatus_is_enabled(const BlockDriverState *bs)
> > +{
> > + return (bs->iostatus != BDRV_IOS_INVAL &&
> > + (bs->on_write_error == BLOCK_ERR_STOP_ENOSPC ||
> > + bs->on_write_error == BLOCK_ERR_STOP_ANY ||
> > + bs->on_read_error == BLOCK_ERR_STOP_ANY));
> > +}
> > +
> > +void bdrv_iostatus_reset(BlockDriverState *bs)
> > +{
> > + if (bdrv_iostatus_is_enabled(bs)) {
> > + bs->iostatus = BDRV_IOS_OK;
> > + }
> > +}
> > +
> > +void bdrv_iostatus_set_err(BlockDriverState *bs, int error)
> > +{
> > + if (bdrv_iostatus_is_enabled(bs) && bs->iostatus == BDRV_IOS_OK) {
> > + bs->iostatus = (abs(error) == ENOSPC) ? BDRV_IOS_ENOSPC :
> > + BDRV_IOS_FAILED;
> > + }
> > +}
> > +
>
> abs(error) feels... unusual.
>
> If you want to guard against callers passing wrongly signed values, why
> not simply assert(error >= 0)?
Yes. Actually, I thought that there were existing devices that could pass
a positive value (while others passed a negative one), but by taking a look
at the code now it seems that all supported devices pass a negative value,
so your suggestion makes sense.
>
> > void
> > bdrv_acct_start(BlockDriverState *bs, BlockAcctCookie *cookie, int64_t bytes,
> > enum BlockAcctType type)
> > diff --git a/block.h b/block.h
> > index 16bfa0a..de74af0 100644
> > --- a/block.h
> > +++ b/block.h
> > @@ -77,6 +77,15 @@ typedef enum {
> > BDRV_ACTION_REPORT, BDRV_ACTION_IGNORE, BDRV_ACTION_STOP
> > } BlockMonEventAction;
> >
> > +typedef enum {
> > + BDRV_IOS_INVAL, BDRV_IOS_OK, BDRV_IOS_FAILED, BDRV_IOS_ENOSPC,
> > + BDRV_IOS_MAX
> > +} BlockIOStatus;
>
> Why is this in block.h?
I followed BlockErrorAction, you suggest block_int.h?
>
> > +
> > +void bdrv_iostatus_enable(BlockDriverState *bs);
> > +void bdrv_iostatus_reset(BlockDriverState *bs);
> > +bool bdrv_iostatus_is_enabled(const BlockDriverState *bs);
> > +void bdrv_iostatus_set_err(BlockDriverState *bs, int error);
> > void bdrv_mon_event(const BlockDriverState *bdrv,
> > BlockMonEventAction action, int is_read);
> > void bdrv_info_print(Monitor *mon, const QObject *data);
> > diff --git a/block_int.h b/block_int.h
> > index 8c3b863..f2f4f2d 100644
> > --- a/block_int.h
> > +++ b/block_int.h
> > @@ -199,6 +199,7 @@ struct BlockDriverState {
> > drivers. They are not used by the block driver */
> > int cyls, heads, secs, translation;
> > BlockErrorAction on_read_error, on_write_error;
> > + BlockIOStatus iostatus;
> > char device_name[32];
> > unsigned long *dirty_bitmap;
> > int64_t dirty_count;
> > diff --git a/monitor.c b/monitor.c
> > index 8ec2c5e..88d8228 100644
> > --- a/monitor.c
> > +++ b/monitor.c
> > @@ -1304,6 +1304,11 @@ struct bdrv_iterate_context {
> > int err;
> > };
> >
> > +static void iostatus_bdrv_it(void *opaque, BlockDriverState *bs)
> > +{
> > + bdrv_iostatus_reset(bs);
> > +}
> > +
> > /**
> > * do_cont(): Resume emulation.
> > */
> > @@ -1320,6 +1325,7 @@ static int do_cont(Monitor *mon, const QDict *qdict, QObject **ret_data)
> > return -1;
> > }
> >
> > + bdrv_iterate(iostatus_bdrv_it, NULL);
> > bdrv_iterate(encrypted_bdrv_it, &context);
> > /* only resume the vm if all keys are set and valid */
> > if (!context.err) {
>
next prev parent reply other threads:[~2011-09-23 14:01 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-22 18:19 [Qemu-devel] [PATCH v2 0/6]: block: Add I/O status support Luiz Capitulino
2011-09-22 18:19 ` [Qemu-devel] [PATCH 1/6] block: Keep track of devices' I/O status Luiz Capitulino
2011-09-23 7:06 ` Zhi Yong Wu
2011-09-23 7:51 ` Markus Armbruster
2011-09-23 7:53 ` Markus Armbruster
2011-09-23 14:01 ` Luiz Capitulino [this message]
2011-09-23 15:36 ` Markus Armbruster
2011-09-23 19:41 ` Luiz Capitulino
2011-09-26 9:34 ` Markus Armbruster
2011-09-26 12:49 ` Luiz Capitulino
2011-09-26 13:41 ` Markus Armbruster
2011-09-22 18:19 ` [Qemu-devel] [PATCH 2/6] virtio: Support " Luiz Capitulino
2011-09-22 18:19 ` [Qemu-devel] [PATCH 3/6] ide: " Luiz Capitulino
2011-09-22 18:19 ` [Qemu-devel] [PATCH 4/6] scsi: " Luiz Capitulino
2011-09-22 18:19 ` [Qemu-devel] [PATCH 5/6] QMP: query-status: Add 'io-status' key Luiz Capitulino
2011-09-22 18:19 ` [Qemu-devel] [PATCH 6/6] HMP: Print 'io-status' information Luiz Capitulino
-- strict thread matches above, loose matches on Subject: below --
2011-09-26 20:43 [Qemu-devel] [PATCH v3 0/6]: block: Add I/O status support Luiz Capitulino
2011-09-26 20:43 ` [Qemu-devel] [PATCH 1/6] block: Keep track of devices' I/O status Luiz Capitulino
2011-09-01 18:37 [Qemu-devel] [PATCH v1 0/6]: block: Add I/O status support Luiz Capitulino
2011-09-01 18:37 ` [Qemu-devel] [PATCH 1/6] block: Keep track of devices' I/O status 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=20110923110100.1f72f0c6@doriath \
--to=lcapitulino@redhat.com \
--cc=armbru@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=zwu.kernel@gmail.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).