aboutsummaryrefslogtreecommitdiff
path: root/block/io.c
diff options
context:
space:
mode:
authorEric Blake <eblake@redhat.com>2017-05-04 21:15:00 -0500
committerFam Zheng <famz@redhat.com>2017-06-30 21:48:06 +0800
commitc61e684e44272f2acb2bef34cf2aa234582a73a9 (patch)
treec11b2d0e9426e92e534ead58f4a498331d023e6f /block/io.c
parentfb0d8654ffc3ea1494067327fc4c4da5d0872724 (diff)
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 <eblake@redhat.com> Message-Id: <20170505021500.19315-3-eblake@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Fam Zheng <famz@redhat.com>
Diffstat (limited to 'block/io.c')
-rw-r--r--block/io.c27
1 files changed, 22 insertions, 5 deletions
diff --git a/block/io.c b/block/io.c
index 7e6abef269..2de7c77983 100644
--- a/block/io.c
+++ b/block/io.c
@@ -1803,10 +1803,13 @@ static int64_t coroutine_fn bdrv_co_get_block_status(BlockDriverState *bs,
/* Ignore errors. This is just providing extra information, it
* is useful but not necessary.
*/
- if (!file_pnum) {
- /* !file_pnum indicates an offset at or beyond the EOF; it is
- * perfectly valid for the format block driver to point to such
- * offsets, so catch it and mark everything as zero */
+ if (ret2 & BDRV_BLOCK_EOF &&
+ (!file_pnum || ret2 & BDRV_BLOCK_ZERO)) {
+ /*
+ * It is valid for the format block driver to read
+ * beyond the end of the underlying file's current
+ * size; such areas read as zero.
+ */
ret |= BDRV_BLOCK_ZERO;
} else {
/* Limit request to the range reported by the protocol driver */
@@ -1833,16 +1836,30 @@ static int64_t coroutine_fn bdrv_co_get_block_status_above(BlockDriverState *bs,
{
BlockDriverState *p;
int64_t ret = 0;
+ bool first = true;
assert(bs != base);
for (p = bs; p != base; p = backing_bs(p)) {
ret = bdrv_co_get_block_status(p, sector_num, nb_sectors, pnum, file);
- if (ret < 0 || ret & BDRV_BLOCK_ALLOCATED) {
+ if (ret < 0) {
+ break;
+ }
+ if (ret & BDRV_BLOCK_ZERO && ret & BDRV_BLOCK_EOF && !first) {
+ /*
+ * Reading beyond the end of the file continues to read
+ * zeroes, but we can only widen the result to the
+ * unallocated length we learned from an earlier
+ * iteration.
+ */
+ *pnum = nb_sectors;
+ }
+ if (ret & (BDRV_BLOCK_ZERO | BDRV_BLOCK_DATA)) {
break;
}
/* [sector_num, pnum] unallocated on this layer, which could be only
* the first part of [sector_num, nb_sectors]. */
nb_sectors = MIN(nb_sectors, *pnum);
+ first = false;
}
return ret;
}