[Libguestfs] [PATCH nbdkit] cache, cow: Export block size constraints

Eric Blake eblake at redhat.com
Mon Feb 21 20:01:52 UTC 2022


On Sun, Feb 20, 2022 at 08:49:08PM +0000, Richard W.M. Jones wrote:
> Because these filters perform a read-modify-write cycle for requests
> which are smaller than the block size of the filter, we can adjust or
> set the preferred block size to the block size of the filter or the
> preferred block size of the underlying plugin, whichever is larger.
> 
> We're careful not to set a preferred block size which is larger than
> the maximum block size.
> 

> diff --git a/filters/cache/cache.c b/filters/cache/cache.c
> index c912c5fb..f0ee42f1 100644
> --- a/filters/cache/cache.c
> +++ b/filters/cache/cache.c
> @@ -260,6 +260,26 @@ cache_get_size (nbdkit_next *next,
>    return size;
>  }
>  
> +/* Block size constraints. */
> +static int
> +cache_block_size (nbdkit_next *next, void *handle,
> +                  uint32_t *minimum, uint32_t *preferred, uint32_t *maximum)
> +{
> +  if (next->block_size (next, minimum, preferred, maximum) == -1)
> +    return -1;
> +
> +  if (*minimum == 0) {         /* No constraints set by the plugin. */
> +    *minimum = 1;
> +    *preferred = blksize;
> +    *maximum = 0xffffffff;
> +  }
> +  else if (*maximum >= blksize) {
> +    *preferred = MAX (*preferred, blksize);
> +  }

We're not changing the minimum or maximum (use blocksize-policy filter
if we want to enforce that before it reaches the plugin), but what you
are changing here makes sense to me - we really are running a
potentially larger preferred I/O size than the plugin based on how our
cache blocks work.

ACK.

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




More information about the Libguestfs mailing list