All of lore.kernel.org
 help / color / mirror / Atom feed
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) {
> 

  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 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.