All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fam Zheng <famz@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: qemu-devel@nongnu.org, kwolf@redhat.com, jsnow@redhat.com,
	qemu-block@nongnu.org, Max Reitz <mreitz@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v3 03/20] file-posix: Switch to .bdrv_co_block_status()
Date: Wed, 20 Sep 2017 17:57:11 +0800	[thread overview]
Message-ID: <20170920095711.GA4058@lemon.lan> (raw)
In-Reply-To: <20170914144032.14945-4-eblake@redhat.com>

On Thu, 09/14 09:40, Eric Blake wrote:
> We are gradually moving away from sector-based interfaces, towards
> byte-based.  Update the file protocol driver accordingly.  In mapping
> mode, note that the entire file is reported as allocated, so we can
> take a shortcut and skip lseek().
> 
> Signed-off-by: Eric Blake <eblake@redhat.com>
> 
> ---
> v2: tweak comment, add mapping support
> ---
>  block/file-posix.c | 57 ++++++++++++++++++++++++++++++------------------------
>  1 file changed, 32 insertions(+), 25 deletions(-)
> 
> diff --git a/block/file-posix.c b/block/file-posix.c
> index 72ecfbb0e0..6813059867 100644
> --- a/block/file-posix.c
> +++ b/block/file-posix.c
> @@ -2107,24 +2107,25 @@ static int find_allocation(BlockDriverState *bs, off_t start,
>  }
> 
>  /*
> - * Returns the allocation status of the specified sectors.
> + * Returns the allocation status of the specified offset.
>   *
> - * If 'sector_num' is beyond the end of the disk image the return value is 0
> + * If 'offset' is beyond the end of the disk image the return value is 0
>   * and 'pnum' is set to 0.
>   *
> - * 'pnum' is set to the number of sectors (including and immediately following
> - * the specified sector) that are known to be in the same
> + * 'pnum' is set to the number of bytes (including and immediately following
> + * the specified offset) that are known to be in the same
>   * allocated/unallocated state.
>   *
> - * 'nb_sectors' is the max value 'pnum' should be set to.  If nb_sectors goes
> + * 'bytes' is the max value 'pnum' should be set to.  If bytes goes
>   * beyond the end of the disk image it will be clamped.
>   */
> -static int64_t coroutine_fn raw_co_get_block_status(BlockDriverState *bs,
> -                                                    int64_t sector_num,
> -                                                    int nb_sectors, int *pnum,
> -                                                    BlockDriverState **file)
> +static int64_t coroutine_fn raw_co_block_status(BlockDriverState *bs,
> +                                                bool mapping,
> +                                                int64_t offset,
> +                                                int64_t bytes, int64_t *pnum,
> +                                                BlockDriverState **file)
>  {
> -    off_t start, data = 0, hole = 0;
> +    off_t data = 0, hole = 0;
>      int64_t total_size;
>      int ret;
> 
> @@ -2133,39 +2134,45 @@ static int64_t coroutine_fn raw_co_get_block_status(BlockDriverState *bs,
>          return ret;
>      }
> 
> -    start = sector_num * BDRV_SECTOR_SIZE;
>      total_size = bdrv_getlength(bs);
>      if (total_size < 0) {
>          return total_size;
> -    } else if (start >= total_size) {
> +    } else if (offset >= total_size) {
>          *pnum = 0;
>          return 0;
> -    } else if (start + nb_sectors * BDRV_SECTOR_SIZE > total_size) {
> -        nb_sectors = DIV_ROUND_UP(total_size - start, BDRV_SECTOR_SIZE);
> +    } else if (offset + bytes > total_size) {
> +        bytes = total_size - offset;
>      }
> 
> -    ret = find_allocation(bs, start, &data, &hole);
> +    if (!mapping) {
> +        *pnum = bytes;
> +        *file = bs;
> +        return BDRV_BLOCK_DATA | BDRV_BLOCK_OFFSET_VALID |
> +            (offset & BDRV_BLOCK_OFFSET_MASK);
> +    }

I may be missing something, because the last time I tried to understand the
rationale behind "mapping" was already some time ago: shouldn't we still
distinguish hole and data? What will omitting BDRV_BLOCK_ZERO help?

Fam

> +
> +    ret = find_allocation(bs, offset, &data, &hole);
>      if (ret == -ENXIO) {
>          /* Trailing hole */
> -        *pnum = nb_sectors;
> +        *pnum = bytes;
>          ret = BDRV_BLOCK_ZERO;
>      } else if (ret < 0) {
>          /* No info available, so pretend there are no holes */
> -        *pnum = nb_sectors;
> +        *pnum = bytes;
>          ret = BDRV_BLOCK_DATA;
> -    } else if (data == start) {
> -        /* On a data extent, compute sectors to the end of the extent,
> +    } else if (data == offset) {
> +        /* On a data extent, compute bytes to the end of the extent,
>           * possibly including a partial sector at EOF. */
> -        *pnum = MIN(nb_sectors, DIV_ROUND_UP(hole - start, BDRV_SECTOR_SIZE));
> +        *pnum = MIN(bytes, hole - offset);
>          ret = BDRV_BLOCK_DATA;
>      } else {
> -        /* On a hole, compute sectors to the beginning of the next extent.  */
> -        assert(hole == start);
> -        *pnum = MIN(nb_sectors, (data - start) / BDRV_SECTOR_SIZE);
> +        /* On a hole, compute bytes to the beginning of the next extent.  */
> +        assert(hole == offset);
> +        *pnum = MIN(bytes, data - offset);
>          ret = BDRV_BLOCK_ZERO;
>      }
>      *file = bs;
> -    return ret | BDRV_BLOCK_OFFSET_VALID | start;
> +    return ret | BDRV_BLOCK_OFFSET_VALID | (offset & BDRV_BLOCK_OFFSET_MASK);
>  }
> 
>  static coroutine_fn BlockAIOCB *raw_aio_pdiscard(BlockDriverState *bs,
> @@ -2259,7 +2266,7 @@ BlockDriver bdrv_file = {
>      .bdrv_close = raw_close,
>      .bdrv_create = raw_create,
>      .bdrv_has_zero_init = bdrv_has_zero_init_1,
> -    .bdrv_co_get_block_status = raw_co_get_block_status,
> +    .bdrv_co_block_status = raw_co_block_status,
>      .bdrv_co_pwrite_zeroes = raw_co_pwrite_zeroes,
> 
>      .bdrv_co_preadv         = raw_co_preadv,
> -- 
> 2.13.5
> 

  reply	other threads:[~2017-09-20 13:33 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-14 14:40 [Qemu-devel] [PATCH v3 00/20] add byte-based block_status driver callbacks Eric Blake
2017-09-14 14:40 ` [Qemu-devel] [PATCH v3 01/20] block: Add .bdrv_co_block_status() callback Eric Blake
2017-09-14 14:40 ` [Qemu-devel] [PATCH v3 02/20] block: Switch passthrough drivers to .bdrv_co_block_status() Eric Blake
2017-09-14 14:40 ` [Qemu-devel] [PATCH v3 03/20] file-posix: Switch " Eric Blake
2017-09-20  9:57   ` Fam Zheng [this message]
2017-09-20 13:47     ` Eric Blake
2017-09-22  5:54       ` Fam Zheng
2017-09-14 14:40 ` [Qemu-devel] [PATCH v3 04/20] gluster: " Eric Blake
2017-09-14 14:40 ` [Qemu-devel] [PATCH v3 05/20] iscsi: Switch cluster_sectors to byte-based Eric Blake
2017-09-14 14:40 ` [Qemu-devel] [PATCH v3 06/20] iscsi: Switch iscsi_allocmap_update() " Eric Blake
2017-09-14 14:40 ` [Qemu-devel] [PATCH v3 07/20] iscsi: Switch to .bdrv_co_block_status() Eric Blake
2017-09-14 14:40 ` [Qemu-devel] [PATCH v3 08/20] null: " Eric Blake
2017-09-14 14:40 ` [Qemu-devel] [PATCH v3 09/20] parallels: " Eric Blake
2017-09-14 14:40 ` [Qemu-devel] [PATCH v3 10/20] qcow: " Eric Blake
2017-09-14 14:40 ` [Qemu-devel] [PATCH v3 11/20] qcow2: " Eric Blake
2017-09-14 14:40 ` [Qemu-devel] [PATCH v3 12/20] qed: " Eric Blake
2017-09-14 14:40 ` [Qemu-devel] [PATCH v3 13/20] raw: " Eric Blake
2017-09-14 14:40 ` [Qemu-devel] [PATCH v3 14/20] sheepdog: " Eric Blake
2017-09-14 14:40 ` [Qemu-devel] [PATCH v3 15/20] vdi: Avoid bitrot of debugging code Eric Blake
2017-09-14 14:40 ` [Qemu-devel] [PATCH v3 16/20] vdi: Switch to .bdrv_co_block_status() Eric Blake
2017-09-14 14:40 ` [Qemu-devel] [PATCH v3 17/20] vmdk: " Eric Blake
2017-09-14 14:40 ` [Qemu-devel] [PATCH v3 18/20] vpc: " Eric Blake
2017-09-14 14:40 ` [Qemu-devel] [PATCH v3 19/20] vvfat: " Eric Blake
2017-09-14 14:40 ` [Qemu-devel] [PATCH v3 20/20] block: Drop unused .bdrv_co_get_block_status() Eric Blake

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=20170920095711.GA4058@lemon.lan \
    --to=famz@redhat.com \
    --cc=eblake@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --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.