[Libguestfs] [PATCH nbdkit 6/8] data, memory: Implement extents.

[Eric Blake]

On 3/28/19 8:18 AM, Richard W.M. Jones wrote:

>> It's a copy and paste from one of the previous sparse_array_*
>> functions in the same file.  I agree that we should return the most
>> possible information and moving the clamp as you suggest is the way to
>> do that.
> 
> So I tried that, but it introduces a subtle error.
> 
> 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,

Hmm - it's one thing for nbdkit to return more status than qemu asked
for, and qemu to just ignore the extra, when that extra status still
covers the advertised image size. But when you are advertising status
beyond EOF, that's easier to argue as being a protocol violation.

Give me a few minutes, and I'll post a patch for an idea I have on a way
to make nbdkit quit returning status beyond EOF, and making it so that
we avoid this subtle issue with the truncate filter.

> 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]

Indeed - wrong because it goes beyond EOF.

> 
> If we leave the test where it is then we get the expected extents:
> 
>   [length=512, type=data]
>   [length=65536-512, type=hole|zero]
> 
> Now it's fair to say this is also caused by the sparse array not
> knowing the real size of the plugin.  We might pass that information
> into the sparse array, but I feel as it's very low cost to query the
> sparse array we might as well do the simpler thing.

I think allowing plugins to report status beyond EOF is nicer for plugin
writers, and therefore the fix should lie in the truncate filter. You'll
see more what I mean once I post the patch.

> 
> Oh yes and I found a bug in qemu, will discuss that in another email :-)

Will followup on that mail :)

-- 
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/20190328/1c74097f/attachment.sig>