summaryrefslogtreecommitdiff
path: root/block.c
diff options
context:
space:
mode:
authorEric Blake <eblake@redhat.com>2018-01-26 13:34:39 -0600
committerEric Blake <eblake@redhat.com>2018-02-09 12:32:44 -0600
commite24d813b29d3a478a9309078487efc8ce8599f22 (patch)
treec55a2783ce46807917db51bfbfda52d6526efec3 /block.c
parent85a353a024dc8dcfbb3a3b8ec6061b1663d903d7 (diff)
downloadqemu-e24d813b29d3a478a9309078487efc8ce8599f22.tar.gz
block: Simplify bdrv_can_write_zeroes_with_unmap()
We don't need the can_write_zeroes_with_unmap field in BlockDriverInfo, because it is redundant information with supported_zero_flags & BDRV_REQ_MAY_UNMAP. Note that BlockDriverInfo and supported_zero_flags are both per-device settings, rather than global state about the driver as a whole, which means one or both of these bits of information can already be conditional. Let's audit how they were set: crypto: always setting can_write_ to false is pointless (the struct starts life zero-initialized), no use of supported_ nbd: just recently fixed to set can_write_ if supported_ includes MAY_UNMAP (thus this commit effectively reverts bca80059e and solves the problem mentioned there in a more global way) file-posix, iscsi, qcow2: can_write_ is conditional, while supported_ was unconditional; but passing MAY_UNMAP would fail with ENOTSUP if the condition wasn't met qed: can_write_ is unconditional, but pwrite_zeroes lacks support for MAY_UNMAP and supported_ is not set. Perhaps support can be added later (since it would be similar to qcow2), but for now claiming false is no real loss all other drivers: can_write_ is not set, and supported_ is either unset or a passthrough Simplify the code by moving the conditional into supported_zero_flags for all drivers, then dropping the now-unused BDI field. For callers that relied on bdrv_can_write_zeroes_with_unmap(), we return the same per-device settings for drivers that had conditions (no observable change in behavior there); and can now return true (instead of false) for drivers that support passthrough (for example, the commit driver) which gives those drivers the same fix as nbd just got in bca80059e. For callers that relied on supported_zero_flags, we now have a few more places that can avoid a wasted call to pwrite_zeroes() that will just fail with ENOTSUP. Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20180126193439.20219-1-eblake@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Diffstat (limited to 'block.c')
-rw-r--r--block.c8
1 files changed, 1 insertions, 7 deletions
diff --git a/block.c b/block.c
index f94585b230..814e5a02da 100644
--- a/block.c
+++ b/block.c
@@ -4010,17 +4010,11 @@ bool bdrv_unallocated_blocks_are_zero(BlockDriverState *bs)
bool bdrv_can_write_zeroes_with_unmap(BlockDriverState *bs)
{
- BlockDriverInfo bdi;
-
if (!(bs->open_flags & BDRV_O_UNMAP)) {
return false;
}
- if (bdrv_get_info(bs, &bdi) == 0) {
- return bdi.can_write_zeroes_with_unmap;
- }
-
- return false;
+ return bs->supported_zero_flags & BDRV_REQ_MAY_UNMAP;
}
const char *bdrv_get_encrypted_filename(BlockDriverState *bs)