Displaying 20 results from an estimated 800 matches similar to: "[nbdkit PATCH] Introduce cacheextents filter"
2019 Jun 11
5
[nbdkit PATCH v2] Introduce cacheextents filter
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`
2019 May 15
6
[nbdkit PATCH v2] Introduce cacheextents filter
This filter caches the last result of the extents() call and offers a nice
speed-up for clients that only support req_on=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
2019 May 20
2
Re: [nbdkit PATCH v2] Introduce cacheextents filter
On Thu, May 16, 2019 at 08:05:18AM -0500, Eric Blake wrote:
>On 5/15/19 5:39 PM, 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_on=1 in combination with plugins like
>
>s/on/one/
>
>> vddk, which has no overhead for returning information for multiple extents in
2019 Jun 11
0
Re: [nbdkit PATCH v2] Introduce cacheextents filter
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
2019 May 15
0
Re: [nbdkit PATCH] Introduce cacheextents filter
On Wed, May 15, 2019 at 02:54:17PM +0200, 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_on=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
2019 May 16
0
Re: [nbdkit PATCH v2] Introduce cacheextents filter
On 5/15/19 5:39 PM, 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_on=1 in combination with plugins like
s/on/one/
> 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
2019 May 20
0
Re: [nbdkit PATCH v2] Introduce cacheextents filter
On 5/20/19 8:23 AM, Martin Kletzander wrote:
>>> + if (cache_extents &&
>>> + offset >= cache_start && offset < cache_end) {
>>> + nbdkit_debug ("cacheextents: returning from cache");
>>> + return cacheextents_add (extents, err);
>>> + }
>>> +
>>> + nbdkit_debug ("cacheextents: cache
2019 Jun 11
0
Re: [nbdkit PATCH v2] Introduce cacheextents filter
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
2019 May 16
0
Re: [nbdkit PATCH v2] Introduce cacheextents filter
Apply the attached patch on top of yours which contains miscellaneous
fixes. If you use ‘./configure --enable-gcc-warnings’ then it will
enable GCC warnings.
The test doesn't really test anything. If extents are being cached
then I have two ideas about how you could see that: Either (1) you
could look at debug messages, the second extents call shouldn't be
processed at the plugin layer.
2019 May 16
1
Re: [nbdkit PATCH v2] Introduce cacheextents filter
On Thu, May 16, 2019 at 08:42:43AM +0100, Richard W.M. Jones wrote:
>
>Apply the attached patch on top of yours which contains miscellaneous
>fixes. If you use ‘./configure --enable-gcc-warnings’ then it will
>enable GCC warnings.
>
Thanks. Again, too much used to libvirt codebase where those are being enabled
by default for builds from git.
>The test doesn't really test
2019 Mar 20
15
[PATCH nbdkit 0/8] Implement extents using a simpler array.
Not sure what version we're up to, but this reimplements extents using
the new simpler structure described in this thread:
https://www.redhat.com/archives/libguestfs/2019-March/msg00077.html
I also fixed most of the things that Eric pointed out in the previous
review, although I need to go back over his replies and check I've got
everything.
This needs a bit more testing. However the
2019 Apr 24
4
[PATCH nbdkit 2/2] filters: Be careful to set *err if nbdkit_add_extent or nbdkit_extents_new fail.
This fix isn't exhaustive but it fixes some obvious problems in the
filters.
Rich.
2019 Mar 26
21
[PATCH nbdkit v4 00/15] Implement Block Status.
I'm not sure exactly which version we're up to, but let's say it's
version 4.
I'm a lot happier with this version:
- all filters have been reviewed and changed where I think that's necessary
- can_extents is properly defined and implemented now
- NBD protocol is followed
- I believe it addresses all previous review points where possible
The "only" thing
2020 Mar 23
6
[PATCH nbdkit 0/3] msys2 support for review
I pushed a few of the msys2 patches upstream. I changed the way that
$(SHARED_LDFLAGS) works so it's more to my liking, and the others were
pushed unchanged. Three patches remain which I'm posting on the
mailing list for proper review.
Rich.
2019 Mar 28
32
[PATCH nbdkit v5 FINAL 00/19] Implement extents.
This has already been pushed upstream. I am simply posting these here
so we have a reference in the mailing list in case we find bugs later
(as I'm sure we will - it's a complex patch series).
Great thanks to Eric Blake for tireless review on this one. It also
seems to have identified a few minor bugs in qemu along the way.
Rich.
2019 Sep 20
1
[PATCH] v2v: Use cacheextents if possible for vddk input
It does not need configuring and speeds up the process of requesting extents if
the client asks for them one by one (like qemu-img).
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
---
v2v/input_libvirt_vddk.ml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/v2v/input_libvirt_vddk.ml b/v2v/input_libvirt_vddk.ml
index a8e4fd5ac78e..cc63f77ce825 100644
---
2019 Nov 14
1
[PATCH v2v v2] nbdkit: Use cacheextents if possible for vddk input
It does not need configuring and speeds up the process of requesting extents if
the client asks for them one by one (like qemu-img).
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
---
Essentially a v2 of the following patch since now there is a probing function:
https://www.redhat.com/archives/libguestfs/2019-September/msg00249.html
v2v/nbdkit.ml | 7 +++++++
1 file changed, 7
2019 Aug 28
1
[nbdkit PATCH] offset, partition: Fix .extents with non-zero offset
When querying the extents of the underlying plugin, we should only
translate the starting offset, and let the plugin report for at least
as many bytes as our range permits. Otherwise, short-changing the
range causes bad behavior such as returning 0 extents, or even failing
the creation of an extents tracker:
$ cat script
case "$1" in
get_size) echo 1m;;
can_extents) ;;
2019 Apr 23
1
Re: [nbdkit PATCH 2/4] filters: Utilize CLEANUP_EXTENTS_FREE
On 4/23/19 2:06 PM, Eric Blake wrote:
> Now that cleanup.h is in common code, we can use it in our
> filters. The first round focuses just on places that called
> nbdkit_extents_free(), as all three callers had multiple exit paths
> that definitely benefit from the macro.
>
> Signed-off-by: Eric Blake <eblake@redhat.com>
> ---
> filters/offset/offset.c | 13
2019 May 21
1
[PATCH nbdkit] protocol: Fix base:allocation replies when req_one is not set.
I pushed this one already. It should go into the stable-1.12 branch too.
Rich.