[Qemu-commits] [qemu/qemu] fb0d86: block: Add BDRV_BLOCK_EOF to bdrv_get_block_status...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: fb0d8654ffc3ea1494067327fc4c4da5d0872724
      
https://github.com/qemu/qemu/commit/fb0d8654ffc3ea1494067327fc4c4da5d0872724
  Author: Eric Blake <address@hidden>
  Date:   2017-06-30 (Fri, 30 Jun 2017)

  Changed paths:
    M block/io.c
    M include/block/block.h

  Log Message:
  -----------
  block: Add BDRV_BLOCK_EOF to bdrv_get_block_status()

Just as the block layer already sets BDRV_BLOCK_ALLOCATED as a
shortcut for subsequent operations, there are also some optimizations
that are made easier if we can quickly tell that *pnum will advance
us to the end of a file, via a new BDRV_BLOCK_EOF which gets set
by the block layer.

This just plumbs up the new bit; subsequent patches will make use
of it.

Signed-off-by: Eric Blake <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Stefan Hajnoczi <address@hidden>
Signed-off-by: Fam Zheng <address@hidden>


  Commit: c61e684e44272f2acb2bef34cf2aa234582a73a9
      
https://github.com/qemu/qemu/commit/c61e684e44272f2acb2bef34cf2aa234582a73a9
  Author: Eric Blake <address@hidden>
  Date:   2017-06-30 (Fri, 30 Jun 2017)

  Changed paths:
    M block/io.c
    M tests/qemu-iotests/154
    M tests/qemu-iotests/154.out

  Log Message:
  -----------
  block: Exploit BDRV_BLOCK_EOF for larger zero blocks

When we have a BDS with unallocated clusters, but asking the status
of its underlying bs->file or backing layer encounters an end-of-file
condition, we know that the rest of the unallocated area will read as
zeroes.  However, pre-patch, this required two separate calls to
bdrv_get_block_status(), as the first call stops at the point where
the underlying file ends.  Thanks to BDRV_BLOCK_EOF, we can now widen
the results of the primary status if the secondary status already
includes BDRV_BLOCK_ZERO.

In turn, this fixes a TODO mentioned in iotest 154, where we can now
see that all sectors in a partial cluster at the end of a file read
as zero when coupling the shorter backing file's status along with our
knowledge that the remaining sectors came from an unallocated cluster.

Also, note that the loop in bdrv_co_get_block_status_above() had an
inefficent exit: in cases where the active layer sets BDRV_BLOCK_ZERO
but does NOT set BDRV_BLOCK_ALLOCATED (namely, where we know we read
zeroes merely because our unallocated clusters lie beyond the backing
file's shorter length), we still ended up probing the backing layer
even though we already had a good answer.

Signed-off-by: Eric Blake <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Stefan Hajnoczi <address@hidden>
Signed-off-by: Fam Zheng <address@hidden>


  Commit: 82d76dc7fc19a5eb9f731d7faed1792bb97214e0
      
https://github.com/qemu/qemu/commit/82d76dc7fc19a5eb9f731d7faed1792bb97214e0
  Author: Peter Maydell <address@hidden>
  Date:   2017-06-30 (Fri, 30 Jun 2017)

  Changed paths:
    M block/io.c
    M include/block/block.h
    M tests/qemu-iotests/154
    M tests/qemu-iotests/154.out

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/famz/tags/block-pull-request' into 
staging

# gpg: Signature made Fri 30 Jun 2017 15:08:45 BST
# gpg:                using RSA key 0xCA35624C6A9171C6
# gpg: Good signature from "Fam Zheng <address@hidden>"
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg:          There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 5003 7CB7 9706 0F76 F021  AD56 CA35 624C 6A91 71C6

* remotes/famz/tags/block-pull-request:
  block: Exploit BDRV_BLOCK_EOF for larger zero blocks
  block: Add BDRV_BLOCK_EOF to bdrv_get_block_status()

Signed-off-by: Peter Maydell <address@hidden>


Compare: https://github.com/qemu/qemu/compare/6db174aed1f7...82d76dc7fc19