Re: [Qemu-block] [Qemu-devel] [PATCH v2 18/32] qcow2: Update qcow2_get_cluster_offset() to support L2 slices

[Alberto Garcia]

On Tue 16 Jan 2018 11:42:45 PM CET, Eric Blake wrote:
> Callers like 'qemu-img map' will potentially have to iterate in more
> steps over an entire image; but that's not a severe limitation.  The
> block_status() functions already document that as long as drivers make
> progress, callers must be prepared for back-to-back calls that return
> the same status, so you are not breaking semantics with a shorter
> clamping limit.
>
> Maybe some of that is worth mentioning in the commit message.  Either
> way,

Yes indeed, for 4KB slices and 64KB clusters each slice can only map
32MB. Then again I don't think that it makes sense to change the slice
size for qemu-img map, or in general for anything that does pure
sequential I/O.

But it's probably worth mentioning in the commit message.

Berto

Re: [Qemu-block] [Qemu-devel] [PATCH v2 18/32] qcow2: Update qcow2_get_cluster_offset() to support L2 slices

[Eric Blake]

On 12/15/2017 06:53 AM, Alberto Garcia wrote:
> qcow2_get_cluster_offset() checks how many contiguous bytes are
> available at a given offset. The returned number of bytes is limited
> by the amount that can be addressed without having to load more than
> one L2 table.
> 
> Since we'll be loading L2 slices instead of full tables this patch
> changes the limit accordingly using the size of the L2 slice for the
> calculations instead of the full table size.
> 
> The l2_table variable is also renamed to l2_slice to reflect this, and
> offset_to_l2_index() is replaced with offset_to_l2_slice_index().
> 
> Signed-off-by: Alberto Garcia 
> ---
>  block/qcow2-cluster.c | 30 +++---
>  1 file changed, 15 insertions(+), 15 deletions(-)
> 

Callers like 'qemu-img map' will potentially have to iterate in more
steps over an entire image; but that's not a severe limitation.  The
block_status() functions already document that as long as drivers make
progress, callers must be prepared for back-to-back calls that return
the same status, so you are not breaking semantics with a shorter
clamping limit.

Maybe some of that is worth mentioning in the commit message.  Either way,

Reviewed-by: Eric Blake 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature