As mentioned in my 'qcow2 zero-cluster tweaks' cover letter https://lists.gnu.org/archive/html/qemu-devel/2017-05/msg00722.html I hit a case where we were not fully optimizing a write-zeroes operation when we have a backing file that is shorter than the active layer, and where the request crosses that boundary. I don't know that the situation will be all that common (most qcow2 files happen to be cluster-aligned in size; and most backing chains use the same length at each layer of the chain), but for RFC purposes, I wanted to explore how easy it would be to optimize the case anyways, and to see if we can think of any other cases where knowing that a block status crossed an end-of-file boundary can be exploited for less work.
Thus, this is a followup to that series, but I'm also okay if we think it is too much maintenance compared to the potential gains, and decide to drop it after all. Another potential use that I thought of: we may someday want to track BDS length by bytes. Right now, bdrv_getlength() returns a value in bytes, but which is sector-aligned, by adding padding; but raw-format.c is able to see the transition between data up to EOF followed by a hole after EOF. Because of that, my series to convert bdrv_get_block_status() into a byte-based interface has to fudge things - any time we see a mid-sector hole being reported, we know it is because we hit EOF, and can round the result up to the next sector boundary. Having the BDRV_BLOCK_EOF flag set in that case may alert clients that the rounding took place, or help us when we quit doing the rounding and actually start tracking BDS lengths by bytes even where it is not sector-aligned. Eric Blake (2): block: Add BDRV_BLOCK_EOF to bdrv_get_block_status() block: Exploit BDRV_BLOCK_EOF for larger zero blocks include/block/block.h | 2 ++ block/io.c | 42 +++++++++++++++++++++++++++++++++--------- tests/qemu-iotests/154 | 4 ---- tests/qemu-iotests/154.out | 12 ++++++------ 4 files changed, 41 insertions(+), 19 deletions(-) -- 2.9.3
