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