On Mon, May 02, 2022 at 10:25:44AM +0100, Nikolaus Rath wrote: At present, no. What are you envisioning - enforcing that the plugin doesn't want to deal with sub-sector offsets and lengths? Is there any other filter that would be useful to require, or can we focus more on the question about insisting on aligned requests? Also, is your plugin mostly worried about enforcement of minimum block size (for example, no requests smaller than 512-byte alignment, which the blocksize filter gives with read-modify-write), or is it also worried about other features that the blocksize filter can add (such as splitting larger requests)? The best you can do in the current code is provide the .block_size callback to at least inform modern NBD clients about your preferences (libnbd defaults to refusing to send requests over the wire that don't obey the server's advertised constraints). I did ask the question when we first added .block_size whether we should also provide a way for plugins to request the internal nbdkit server code to enforce limits (use of the nbdkit-blocksize-filter with read-modify-write is one way to obey underlying limits; but another way is to just up-front fail unaligned requests rather than passing them into the plugin). We could either do this by enhancing the existing .block_size() function to add in a special return value to insist on strict enforcement (right now, we only document returning -1 on error and 0 when successfully populating limits; we could add a documented return of 1), or by adding yet another callback (for example, if .strict_block_size is absent or returns 0, .block_size values are advisory to the client, but unaligned values reach the plugin; if .strict_block_size returns 1, .block_size values are enforced by nbdkit before reaching the plugin). Thoughts about that approach? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org

On Mon, May 02, 2022 at 10:25:44AM +0100, Nikolaus Rath wrote: No it's not possible in general, you just have to document it. However as it's *blocksize* filter that you're talking about, I assume you mean that your filter has blocksize constraints, eg. that it cannot handle sub-sector requests. In this case it is possible to tell clients that they must not issue requests smaller than a certain size (and also hint about optimal and maximum sizes). You can do this by writing a .block_size callback. For example: https://gitlab.com/nbdkit/nbdkit/-/blob/1f5dc0679e570ca2fa149ceaa52922d70... Not all clients obey these (although these clients are buggy!) In particular nbdcopy does not obey the minimum constraint, which actually causes a bug for us in virt-v2v. There's a long thread about it on qemu-devel of which the most important message is: https://www.mail-archive.com/qemu-devel@nongnu.org/msg865252.html I would advertise a block size constraint in your plugin, and if you find a client that doesn't request & then obey this constraint, get the author of the client to fix it :-) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top

On Wed, May 04, 2022 at 09:04:06AM +0100, Nikolaus Rath wrote: It doesn't seem to, from looking at the code. Yes. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html