On Sun, Feb 20, 2022 at 08:56:37PM +0000, Richard W.M. Jones wrote:
This filter is a little unusual because it allows clients to send a
wider range of request sizes than the underlying plugin allows.
Therefore we advertise the widest possible minimum and maximum block
size to clients.
We still need to pick a suitable preferred block size assuming the
plugin itself doesn't advertise one.
---
filters/blocksize/blocksize.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/filters/blocksize/blocksize.c b/filters/blocksize/blocksize.c
index a6fa00cb..46e759b0 100644
--- a/filters/blocksize/blocksize.c
+++ b/filters/blocksize/blocksize.c
@@ -156,6 +156,29 @@ blocksize_get_size (nbdkit_next *next,
return ROUND_DOWN (size, minblock);
}
+/* Block size constraints.
+ *
+ * Note that the purpose of this filter is to allow clients to send a
+ * wider range of request sizes than the underlying plugin permits,
+ * and therefore this callback advertises the full availability of the
+ * filter, likely widening the constraints from the plugin.
+ */
+static int
+blocksize_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 (*preferred == 0)
+ *preferred = MAX (4096, minblock);
Hmm. Even if minblock > *maximum reported by the plugin,...
+
+ *minimum = 1;
+ *maximum = 0xffffffff;
...our advertisement to the client does not trigger any asserts.
ACK.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization:
qemu.org |
libvirt.org