[Libguestfs] [PATCH nbdkit v5 FINAL 14/19] data, memory: Implement extents.

[Eric Blake]

On 4/23/19 4:49 PM, Richard W.M. Jones wrote:

>>
>> ...to here, after the final nbdkit_add_extent, so that we can return a
>> larger extent than the client's request. I remember when I originally
>> asked, you declined due to odd interactions with REQ_ONE semantics, but
>> since then, we changed how add_extent() works. Does it work now to defer
>> the clamping?
> 
> It's a bit late at night for me to think clearly about extents, but
> here is a description of the original problem with moving the clamp:
> 
> https://www.redhat.com/archives/libguestfs/2019-March/msg00202.html

Thanks for finding that link:

> Imagine an allocated RAM disk with a size smaller than the 32K page
> size of the sparse array:
> 
>   nbdkit data data="1" size=512
> 
> This will return extents information: [length=32768, type=data].
> 
> This doesn't matter for qemu which appears to ignore the extra
> information, but it causes a bug if we place the truncate filter on
> top:
> 
>   nbdkit --filter=truncate data data="1" size=512 truncate=64K
> 
> This now returns the following extents information which is wrong:
> 
>   [length=32768, type=data]
>   [length=32768, type=hole|zero]

But since then, we've fixed the truncate filter to allocate a second
extents bounded by the truncation size to hand to next_ops->extents, so
even if the plugin calls nbdkit_add_extent with information beyond the
length that the truncation filter cares about, the result is still
bounded to the truncation's choice of end offset. So I think we have
indeed fixed the initial problem.

> I'll see if this still applies tomorrow morning ...

No rush :)

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20190423/f247a238/attachment.sig>