Re: [Libguestfs] [PATCH nbdkit 6/8] data, memory: Implement extents.
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
Attachments:
- signature.asc (application/pgp-signature — 488 bytes)