[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