Libguestfs - Jan 2022 - [PATCH libnbd] copy: Implement destination preferred block size

On Sun, Jan 30, 2022 at 11:10 AM Richard W.M. Jones <rjones at redhat.com>
wrote:
>
> On Sun, Jan 30, 2022 at 12:45:37AM +0200, Nir Soffer wrote:
> > On Fri, Jan 28, 2022 at 10:37 PM Richard W.M. Jones <rjones at
redhat.com> wrote:
> > > +  .get_preferred_block_size = nbd_ops_get_preferred_block_size,
> >
> > Why preferred block size and not minimum block size? For example if we
> > write 256k when the minimum block size is 64k, wouldn't qemu block
layer
> > handle the write properly, creating 4 compressed clusters?
>
> My theory was that if the destination prefers a particular block size,
> and we're going to all this effort anyway, we might as well use the
> preference.  For the qcow2/compress filter the two values are
> identical.
>
> > When not using a compress filter, qemu-nbd reports block size of 4k,
and
> > using this value it will kill performance.
>
> Not sure I understand?
I think this was a mistake - if we use the preferred size only for
alignment, not
for limiting the size of the requests, it should be ok to use the
preferred block size.

On Sun, Jan 30, 2022 at 06:18:03PM +0200, Nir Soffer
wrote:
> On Sun, Jan 30, 2022 at 11:10 AM Richard W.M. Jones <rjones at
redhat.com> wrote:
> >
> > On Sun, Jan 30, 2022 at 12:45:37AM +0200, Nir Soffer wrote:
> > > On Fri, Jan 28, 2022 at 10:37 PM Richard W.M. Jones <rjones at
redhat.com> wrote:
> > > > +  .get_preferred_block_size =
nbd_ops_get_preferred_block_size,
> > >
> > > Why preferred block size and not minimum block size? For example
if we
> > > write 256k when the minimum block size is 64k, wouldn't qemu
block layer
> > > handle the write properly, creating 4 compressed clusters?
> >
> > My theory was that if the destination prefers a particular block size,
> > and we're going to all this effort anyway, we might as well use
the
> > preference.  For the qcow2/compress filter the two values are
> > identical.
> >
> > > When not using a compress filter, qemu-nbd reports block size of
4k, and
> > > using this value it will kill performance.
> >
> > Not sure I understand?
> 
> I think this was a mistake - if we use the preferred size only for
> alignment, not
> for limiting the size of the requests, it should be ok to use the
> preferred block size.
Got it.

Anyhow let's discuss in more detail if I ever get a patch series that
works!  We probably need to make the various blocksize(s) into a
configuration option.

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