qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 3/8] block: Support to keep track of I/O status


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH 3/8] block: Support to keep track of I/O status
Date: Tue, 12 Jul 2011 09:45:03 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Luiz Capitulino <address@hidden> writes:

> This commit adds support to the BlockDriverState type to keep track
> of the last I/O status. That is, at every I/O operation we update
> a status field in the BlockDriverState instance. Valid statuses are:
> OK, FAILED and ENOSPC.
>
> ENOSPC is distinguished from FAILED because an management application
> can use it to implement thin-provisioning.
>
> This feature has to be explicit enabled by buses/devices supporting it.

buses?

>
> Signed-off-by: Luiz Capitulino <address@hidden>
> ---
>  block.c     |   18 ++++++++++++++++++
>  block.h     |    7 +++++++
>  block_int.h |    2 ++
>  3 files changed, 27 insertions(+), 0 deletions(-)
>
> diff --git a/block.c b/block.c
> index 24a25d5..cc0a34e 100644
> --- a/block.c
> +++ b/block.c
> @@ -195,6 +195,7 @@ BlockDriverState *bdrv_new(const char *device_name)
>      if (device_name[0] != '\0') {
>          QTAILQ_INSERT_TAIL(&bdrv_states, bs, list);
>      }
> +    bs->iostatus_enabled = false;
>      return bs;
>  }
>  
> @@ -2876,6 +2877,23 @@ int bdrv_in_use(BlockDriverState *bs)
>      return bs->in_use;
>  }
>  
> +void bdrv_enable_iostatus(BlockDriverState *bs)
> +{
> +    bs->iostatus_enabled = true;
> +}
> +
> +void bdrv_iostatus_update(BlockDriverState *bs, int error)
> +{
> +    error = abs(error);
> +
> +    if (!error) {
> +        bs->iostatus = BDRV_IOS_OK;
> +    } else {
> +        bs->iostatus = (error == ENOSPC) ? BDRV_IOS_ENOSPC :
> +                                           BDRV_IOS_FAILED;
> +    }
> +}
> +
>  int bdrv_img_create(const char *filename, const char *fmt,
>                      const char *base_filename, const char *base_fmt,
>                      char *options, uint64_t img_size, int flags)
> diff --git a/block.h b/block.h
> index 859d1d9..0dca1bb 100644
> --- a/block.h
> +++ b/block.h
> @@ -50,6 +50,13 @@ typedef enum {
>      BDRV_ACTION_REPORT, BDRV_ACTION_IGNORE, BDRV_ACTION_STOP
>  } BlockMonEventAction;
>  
> +typedef enum {
> +    BDRV_IOS_OK, BDRV_IOS_FAILED, BDRV_IOS_ENOSPC
> +} BlockIOStatus;
> +
> +void bdrv_iostatus_update(BlockDriverState *bs, int error);
> +void bdrv_enable_iostatus(BlockDriverState *bs);
> +void bdrv_enable_io_status(BlockDriverState *bs);
>  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 1e265d2..09f038d 100644
> --- a/block_int.h
> +++ b/block_int.h
> @@ -195,6 +195,8 @@ struct BlockDriverState {
>         drivers. They are not used by the block driver */
>      int cyls, heads, secs, translation;
>      BlockErrorAction on_read_error, on_write_error;
> +    bool iostatus_enabled;
> +    BlockIOStatus iostatus;
>      char device_name[32];
>      unsigned long *dirty_bitmap;
>      int64_t dirty_count;

Okay, let's see what we got here.

The block layer merely holds I/O status, device models set it.

Device I/O status is not migrated.  Why?

bdrv_new() creates the BDS with I/O status tracking disabled.  Devices
that do tracking enable it in their qdev init method.  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().

Actually, this is a symptom of the midlayer disease.  I suspect things
would be simpler if we hold the status in its rightful owner, the device
model.  Need a getter for it.  I'm working on a patch series that moves
misplaced state out of the block layer into device models and block
drivers, and a I/O status getter will fit in easily there.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]