[Libguestfs] [nbdkit PATCH v2] Introduce cacheextents filter

Martin Kletzander mkletzan at redhat.com
Wed Jun 12 21:43:23 UTC 2019


On Tue, Jun 11, 2019 at 02:42:29PM -0500, Eric Blake wrote:
>On 6/11/19 3:49 AM, Martin Kletzander wrote:
>> This filter caches the last result of the extents() call and offers a nice
>> speed-up for clients that only support req_one=1 in combination with plugins
>> like vddk, which has no overhead for returning information for multiple extents
>> in one call, but that call is very time-consuming.
>>
>> Quick test showed that on a fast connection and a sparsely allocated 16G disk
>> with a OS installed `qemu-img map` runs 16s instead of 33s (out of which it
>> takes 5s to the first extents request).  For 100G disk with no data on it, that
>> is one hole extent spanning the whole disk (where there is no space for
>> improvement) this does not add any noticeable overhead.
>>
>> Signed-off-by: Martin Kletzander <mkletzan at redhat.com>
>> ---
>>
>
>> +
>> +/* This lock protects the global state. */
>> +static pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
>> +
>> +/* Cached extents from the last extents () call and its start and end for the
>> +   sake of simplicity. */
>> +struct nbdkit_extents *cache_extents;
>> +static uint64_t cache_start;
>> +static uint64_t cache_end;
>
>This shares a common cache across multiple connections. If the plugin
>ever returns connection-dependent differences (such as different sizes
>according to when the connection was made), we may have to change this
>to track a cache per connection. But then again, this is not the only
>filter to have that issue (at least the cache filter has the same issue
>of assuming that it can share a single cache among all connections).
>

Well, I specifically changed this so that it doesn't cache the size of the
image.  In this case the cache would be invalid if someone modified the image
locally without the use of nbdkit.  That is something you cannot avoid.  With a
per-connection cache it would be invalid if any other connection did a
write/discard/zero as it would not update the caches for other connections.  So
I think this is actually a better approach in the end.

>--
>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: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20190612/820d23d5/attachment.sig>


More information about the Libguestfs mailing list