summaryrefslogtreecommitdiff
path: root/include/block
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 /include/block
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 'include/block')
-rw-r--r--include/block/block.h11
1 files changed, 0 insertions, 11 deletions
diff --git a/include/block/block.h b/include/block/block.h
index 24ef816960..19b3ab9cb5 100644
--- a/include/block/block.h
+++ b/include/block/block.h
@@ -27,17 +27,6 @@ typedef struct BlockDriverInfo {
*/
bool unallocated_blocks_are_zero;
/*
- * True if the driver can optimize writing zeroes by unmapping
- * sectors. This is equivalent to the BLKDISCARDZEROES ioctl in Linux
- * with the difference that in qemu a discard is allowed to silently
- * fail. Therefore we have to use bdrv_pwrite_zeroes with the
- * BDRV_REQ_MAY_UNMAP flag for an optimized zero write with unmapping.
- * After this call the driver has to guarantee that the contents read
- * back as zero. It is additionally required that the block device is
- * opened with BDRV_O_UNMAP flag for this to work.
- */
- bool can_write_zeroes_with_unmap;
- /*
* True if this block driver only supports compressed writes
*/
bool needs_compressed_writes;